ED's Development

20240320

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로 선인덱싱 가능.

그런데 안 옮길 이유

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

절충

tier로 나눔.

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

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