pgvector vs Qdrant 운영 비교

vector 수가 900만 돌파. 지금까지 pgvector 하나로 버텼는데 서비스 DB와 같은 인스턴스에 있다 보니 부담이 커진다. Qdrant로 이관 검토.

비교 포인트

• Qdrant: Rust로 작성, gRPC/HTTP, payload filtering 네이티브.
• pgvector 0.7 예정 기능(halfvec, binary quant)이 매력적인데 아직 stable 아님.

같은 데이터(900만 × 1024dim) 비교

                   pgvector(HNSW)   Qdrant(HNSW)
index build        2h 50m           41m
index size         48 GB            27 GB (on-disk payload sep)
p50 (k=20, filter) 38 ms            9 ms
p99                210 ms           34 ms
cost (동급 VM)       1x              1x (별도 클러스터 필요)

Qdrant가 빠르고 인덱스도 작다. 특히 필터가 있는 쿼리에서 차이가 큼. pgvector는 prefilter가 인덱스 성능을 많이 갉아먹는데, Qdrant는 payload index로 선인덱싱 가능.

그런데 안 옮길 이유

1. 운영 복잡도. 클러스터 하나 더 늘어남. 모니터링/백업/장애 대응이 새 축.
2. Transactional consistency. 사용자 데이터와 vector가 같이 움직여야 하는 테이블은 pgvector가 짝궁. 외부 Qdrant면 sync drift 관리해야 함.
3. 스키마 변경. 기존 JOIN 쿼리가 많음.

절충

tier로 나눔.

• 상품/유저/거래 관련 vector(실시간 필터 강한 쪽) → pgvector 유지, 별도 replica로 분리.
• FAQ/문서/블로그 등 검색 전용 → Qdrant 신설.

이관하면서 배운 것: cosine similarity vs dot product의 차이를 과소평가하면 recall이 눈에 띄게 깎인다. pgvector에서 vector_cosine_ops로 인덱싱해놓고 Qdrant에선 Distance.Cosine으로 맞추는 등, 거리 함수 통일을 꼭 체크.

pgvector 실전 — IVFFlat vs HNSW

pgvector 0.4.0이 얼마 전 나왔고 HNSW 인덱스가 추가됐다 (정확히는 곧 0.5.0 예정). IVFFlat만 쓰다가 비교해볼 기회가 생겨서 같은 데이터셋 170만 row × 1536 dim(ada-002)로 돌려봤다.

인덱스 빌드

-- IVFFlat
CREATE INDEX ON docs USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 1300);   -- sqrt(N) 근처

-- HNSW
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

지표	IVFFlat	HNSW
빌드 시간	4분 20초	38분
인덱스 크기	1.1 GB	3.4 GB
p50 query (k=10)	28 ms	6 ms
recall@10	0.91 (probes=10)	0.98 (ef_search=40)

HNSW가 쿼리는 4배 이상 빠른데 빌드가 훨씬 느리고 메모리 + 디스크를 많이 먹는다. 그리고 insert가 들어올 때마다 graph를 재구성하는 비용이 있어서 write 많은 테이블엔 조심해야 함.

IVFFlat은 lists 값에 엄청 민감한데, 일반적으로 rows/1000 ~ sqrt(rows) 사이에서 튜닝한다. probes를 올리면 recall이 올라가는데 latency가 선형 증가. 우리 케이스는 probes=10 근처가 accuracy-speed 절충점.

결론(지금 시점)

• read-heavy, static data → HNSW
• write가 계속 들어오는 테이블 → IVFFlat (혹은 HNSW에 create partial index)
• 수백만~수천만 row면 Qdrant나 Milvus 고려 시작해야 할 듯. 아직 우리는 안 감.

pgvector 0.5 안정화되면 HNSW가 거의 기본이 될 것 같다는 생각.

Vector DB 처음 써봄 — Milvus vs Weaviate

상품 유사도 추천에 임베딩 기반 검색을 붙여보려고 vector DB 두 개를 비교 테스트. Milvus 2.0(작년 11월쯤 2.0 GA), Weaviate 1.10. 둘 다 처음 써봄. 솔직히 관련 지식 얕아서 사용기 수준.

데이터

상품 텍스트(이름+설명) 임베딩 300만 벡터, 차원 768(multilingual sentence embedding). query 당 top-10 ANN 검색.

설치

Milvus는 docker-compose로 minio+etcd+pulsar까지 같이 올라옴. 처음 보면 어질어질함.

wget https://github.com/milvus-io/milvus/releases/download/v2.0.0/milvus-standalone-docker-compose.yml
docker compose up -d

Weaviate는 훨씬 가볍.

services:
  weaviate:
    image: semitechnologies/weaviate:1.10.0
    ports: ["8080:8080"]
    environment:
      QUERY_DEFAULTS_LIMIT: 25
      DEFAULT_VECTORIZER_MODULE: 'none'

색인 구성

둘 다 HNSW 인덱스. 파라미터는 M=16, efConstruction=200로 맞췄다. 검색 시 ef는 64.

결과

항목	Milvus 2.0	Weaviate 1.10
인덱스 빌드 (3M)	약 18분	약 32분
p95 latency (top-10)	22ms	31ms
recall@10	0.94	0.93
메모리	약 12GB	약 9GB
운영 단순성	낮음(컴포넌트 많음)	높음
메타데이터 필터	OK	GraphQL 기반, 표현력 높음

개인적 인상

성능만 보면 Milvus가 미세하게 좋고 확장성도 강해 보인다. 그런데 운영할 컴포넌트가 많아서 처음 도입에 부담. Weaviate는 단일 바이너리 가까운 느낌이라 실험 단계엔 훨씬 편하다. GraphQL 쿼리 인터페이스는 익숙해지면 편리한데 팀 전체가 학습해야 됨.

결정: PoC 단계에서는 Weaviate로 간다. 트래픽 올라가면 Milvus 재검토. 어차피 벡터 자체는 재업로드만 하면 되니 락인은 작음.

공통 주의점

• 벡터 DB만 있다고 검색이 좋아지진 않는다. 임베딩 품질이 전부임. 다국어 문제 심각한 카테고리(전기용품 등)는 임베딩 모델 튜닝이 먼저.
• ANN 파라미터(ef, M) 따라 recall/latency 트레이드오프 큼. 실데이터로 튜닝 필수.
• vector index rebuild 시간 고려. 스키마 변경이 무겁다.