로컬 벡터DB, RAG 용도별로 무엇을 기준으로 골라야 할까?
결론부터 말하면, 로컬 벡터DB 선택은 "가장 빠른 제품"을 찾는 문제가 아니라 우리 RAG의 쿼리 패턴에서 p95/p99 latency와 목표 recall을 유지하는 비용을 무엇으로 맞추느냐의 문제였다. 문서량, 필터 유무, 운영 인력 수준에 따라 답이 갈렸고, 한 제품이 모든 케이스에서 유리하지는 않았다. 이 글은 그 갈림을 실험 형태로 검증한 기록이다.
- 비교의 핵심 축은 recall, p95/p99 latency, 비용, 운영 난이도 네 가지였다.
- metadata filter가 많은 RAG는 단순 벡터 검색보다 p95/p99가 크게 나빠지는 경향이 반복해서 관찰됐다.
- 이미 PostgreSQL을 운영 중인 팀이라면 pgvector/pgvectorscale이 별도 DB 없이 갈 수 있는 선택지였다.
- ChromaDB 같은 가벼운 로컬 구성은 프로토타입에는 편했지만, 메모리 사용량 차이가 커서 프로덕션 전환 전 재측정이 필요했다.
이번에 검증하려 한 건 단순했다. "로컬에서 RAG를 돌릴 때, 벡터DB 선택이 실제로 쿼리 패턴에 따라 달라지는가?" 사내에서 후보군으로 Qdrant, Milvus, PostgreSQL+pgvector, ChromaDB 네 가지가 거론됐고, 각각 문서량을 다르게 붙여보며 공개 벤치마크와 우리 조건이 얼마나 겹치는지를 먼저 확인했다. 2026년 기준으로 공개된 벤치마크 자료들이 늘어서, 처음부터 완전히 맨땅에서 측정할 필요는 없었다.
RAG 쿼리 패턴을 어떻게 나눠서 비교해야 할까?
문서량, 필터 유무, 이미 쓰고 있는 인프라 여부 세 축으로 나눠야 비교가 의미 있어졌다. 세 시나리오를 세웠다. (1) 문서 수십만~수백만, 필터 거의 없음, 로컬/사내망에서 빠르게 돌릴 RAG, (2) 이미 Postgres가 운영 중이고 벡터 검색만 추가하는 경우, (3) metadata filter가 많고 운영 단순성이 중요한 경우다.
공개 자료에서 눈에 띄는 건 Timescale이 공개한 pgvectorscale 사례였다. 50M 벡터, 1536차원, 99% recall 조건에서 471 QPS를 기록했고, 같은 조건에서 Pinecone의 storage-optimized index 대비 p95 latency가 28배 낮고 throughput은 16배 높다는 결과가 나왔다. self-hosted AWS EC2 기준으로 비용은 75% 낮다는 비교도 같이 제시됐다. 우리처럼 이미 Postgres 위에서 RAG를 돌리던 팀에게는 이 수치가 "별도 DB를 늘리지 않아도 되는" 근거로 읽혔다.
1M 벡터, 1536차원 조건의 다른 비교에서는 Qdrant OSS가 p50 4ms / p99 25ms / recall@10 0.99, Milvus OSS가 p50 6ms / p99 35ms / recall@10 0.99, Pinecone Serverless가 p50 8ms / p99 45ms / recall@10 0.99, Weaviate OSS와 ChromaDB가 각각 p50 12ms대 / p99 65~70ms / recall@10 0.98 수준으로 나왔다. 순위가 명확히 갈렸다기보다, "필터 없는 순수 벡터 검색"에서는 p99 25~45ms 사이에 여러 제품이 몰려 있다고 보는 게 더 정확했다.
필터가 많은 RAG에서는 어떤 게 달라질까?
필터가 늘어나면 p95/p99가 급격히 나빠지는 패턴이 실측에서도 반복됐다. Redis가 공개한 SIFT10M 자료에서는 recall 목표를 0.8에서 0.95로 올렸을 때 HNSW latency가 약 31% 증가했고, IVF는 같은 구간에서 거의 3배가 됐다. 필터 조건 자체는 아니지만, recall을 끌어올리는 방향의 압력이 인덱스 탐색 범위를 넓힌다는 점에서 metadata filter가 많은 RAG와 비슷한 메커니즘으로 읽을 수 있었다.
우리 쪽 구현에서는 필터를 3개 이상 걸었을 때 특정 엔진에서 p99가 예상보다 크게 튀는 걸 봤다. 정확한 원인 분리까지는 못 갔지만, 필터 조건이 많을수록 "평균 latency"만 보고 판단하면 위험하다는 감을 얻었다. 2026년 벡터DB 평가 가이드들도 filter가 많은 경우 ANN 인덱스와 필터 처리의 결합 성능을 별도로 봐야 한다고 정리하는데, 우리 경험과 방향이 겹쳤다.
로컬 운영 환경에서 실제로 뭘 재현할 수 있었을까?
공개 벤치마크 수치를 그대로 재현하긴 어려웠지만, 순위와 경향은 우리 환경에서도 비슷하게 나타났다. 공개 자료에서는 single-thread throughput 기준으로 Redis가 764 QPS, LanceDB가 70 QPS로 10배 차이가 났고, peak memory는 Milvus OSS가 17.0GB, ChromaDB가 62.4GB로 크게 벌어졌다.
우리가 실제로 부딪힌 마찰은 "동일 임베딩, 동일 쿼리 조건"을 맞추는 작업 자체였다. 인덱스 파라미터(HNSW의 M, ef 값 등)를 제품마다 다르게 잡아야 했고, 같은 recall 목표를 맞추려면 제품별로 다른 튜닝이 필요했다. 이 튜닝 차이를 무시하고 기본값끼리 비교하면 실제 성능 차이인지 설정 차이인지 구분이 안 됐다. 여기서 시간이 예상보다 많이 들었다.
공개 벤치마크는 이 판단을 어디까지 뒷받침할까?
대규모 벤치마크는 우리 규모보다 훨씬 큰 조건이라 참고치로만 썼다. 2026년 공개된 벤치마크 요약에서는 Zilliz Cloud가 9,704 QPS / p99 2.5ms, Milvus 3,465 QPS, OpenSearch 3,055 QPS, Qdrant 1,242 QPS, Pinecone 1,147 QPS, Elasticsearch 597 QPS로 나타났다.
| 제품 | 조건 | QPS/latency |
|---|---|---|
| Zilliz Cloud | 공개 벤치마크 | 9,704 QPS, p99 2.5ms |
| Milvus | 공개 벤치마크 | 3,465 QPS |
| OpenSearch | 공개 벤치마크 | 3,055 QPS |
| Qdrant | 공개 벤치마크 | 1,242 QPS |
| Pinecone | 공개 벤치마크 | 1,147 QPS |
또 VAST Data가 제시한 50B vectors, 128차원, multi-process workload 비교에서는 Milvus 약 89 QPS 대비 VAST 약 1000 QPS로 11배 이상 차이가 났고, 검색 1,000건당 비용이 약 91% 줄었다는 결과도 있었다. 이 정도 규모는 우리 로컬 RAG와는 거리가 있어서, "이런 규모가 되면 이런 방향의 격차가 생길 수 있다"는 참고선으로만 남겨뒀다.
이 비교가 못 잡아내는 건 뭘까?
여기까지 확인한 수치들은 원문 공개 문서의 버전과 측정 환경에 따라 달라질 수 있다는 전제를 벗어나지 않는다. 우리 로컬 환경은 VAST의 50B/멀티프로세스 규모와도 다르고, 각 벤치마크가 사용한 하드웨어, 임베딩 차원, 인덱스 파라미터도 모두 달랐다. 같은 제품이라도 튜닝에 따라 순위가 바뀔 수 있다는 걸 우리 쪽 재현에서도 확인했다.
또 하나, filter 조합의 다양성은 실제 RAG마다 완전히 다르다. metadata 필드가 몇 개인지, 필터가 AND/OR 어느 쪽인지에 따라 같은 제품 안에서도 결과가 크게 달랐다. 이 글의 수치는 "어느 제품이 이 조건에서는 이렇게 나왔다"는 기록이지, 우리 RAG에 그대로 옮겨 쓸 수 있는 확정값은 아니다.
결국 무엇을 남겨야 할까?
처음엔 "가장 빠른 벡터DB"를 찾으려 했고, 그건 실패한 접근이었다. 조건을 고정하지 않고 여러 벤치마크 수치를 비교하려 하니 기준이 계속 흔들렸다. 대신 방향을 바꿔서, 우리 RAG의 조건(문서량, 필터 유무, 기존 인프라)에 맞는 후보 2~3개로 좁히고, 그 후보만 우리 쿼리 로그로 재측정하는 쪽으로 정리했다.
다음 실험은 실제 사내 RAG 쿼리 로그를 가지고 Qdrant와 pgvectorscale 두 후보만 놓고 recall-latency 곡선을 직접 그려보는 것이다. 공개 벤치마크는 방향을 잡는 데는 유용했지만, 최종 결정은 결국 우리 쿼리 패턴으로 다시 찍어봐야 한다는 걸 이번 실험에서 다시 확인했다.
핵심 정리
- 벡터DB 비교는 recall, p95/p99 latency, 비용, 운영 난이도 네 축으로 봐야 의미가 있었다.
- 이미 Postgres 위에서 RAG를 돌리는 팀은 pgvector/pgvectorscale이 별도 DB 없이 갈 수 있는 선택지로 확인됐다(50M 벡터, 99% recall 조건에서 471 QPS, self-hosted 비용 75% 절감 사례).
- filter가 많은 RAG는 순수 벡터 검색보다 p95/p99가 나빠지는 경향이 있어 필터+ANN 결합 성능을 따로 봐야 했다.
- 대규모·고동시성 조건(VAST, Zilliz Cloud 등)의 수치는 우리 로컬 규모와 거리가 있어 참고치로만 다뤘다.
- 최종 판단은 공개 벤치마크가 아니라, 좁힌 후보군을 실제 쿼리 로그로 재측정하는 단계에서 나왔다.