[RESEARCH-2026-W39] 벡터 DB 비교 2026 — Qdrant·Milvus·pgvector

벡터 DB 비교의 결론부터 적는다. 이미 PostgreSQL을 운영 중이고 벡터가 1천만 건 아래라면 pgvector가 맞다. 검색 지연과 필터링 성능이 서비스 품질을 결정한다면 Qdrant, 수억 건 이상을 분산으로 다뤄야 한다면 Milvus, 노트북 위 프로토타입이라면 Chroma다. 이 네 갈래를 벗어나는 경우는 생각보다 드물다.

이 문서는 2026년 9월 21일 기준으로 각 프로젝트의 공식 저장소와 문서에서 직접 확인한 버전·기능·제약만 정리한 것이다. 벡터 DB 비교 글이 흔히 빠지는 함정은 벤더가 자사 제품을 1위로 놓은 벤치마크 그래프를 그대로 옮기는 것인데, 여기서는 그런 수치를 인용할 때 출처와 측정 시점을 같이 남겼다. 숫자보다 중요한 건 “내 데이터 규모와 운영 인력에서 어느 쪽이 덜 깨지는가”이기 때문이다.

범위를 먼저 밝힌다. 이 글은 pgvector·Qdrant·Milvus·Chroma 네 엔진을 “운영 난이도·데이터 규모” 축으로 비교한다. Weaviate를 포함해 Qdrant·Milvus와 자가호스팅 성능·라이선스를 더 깊이 파고든 비교가 필요하면 Qdrant vs Milvus vs Weaviate 비교를 참고하라. 그 글은 Weaviate를 더해 전용 검색 엔진 3종에 집중하고, 이 글은 Postgres 내장형(pgvector)과 프로토타입용(Chroma)까지 넓혀 선택지 자체를 결정하는 단계에 맞춘다.

선택을 가르는 축은 사실 세 개뿐이다. 첫째, 벡터를 기존 관계형 데이터와 JOIN해야 하는가. 둘째, 메모리에 올릴 수 없는 규모인가. 셋째, 운영을 전담할 사람이 있는가. 세 질문의 답이 각각 “예 / 아니오 / 아니오”면 pgvector에서 끝난다. 나머지 조합에서만 전용 엔진을 고민할 가치가 있다.

아래에서는 네 후보의 최신 릴리스 상태, 인덱스와 양자화 옵션, 실제 운영에서 부딪히는 한계, 그리고 상황별 추천을 순서대로 다룬다. RAG 파이프라인 전체를 설계 중이라면 임베딩 모델과 청크 전략이 벡터 DB 선택보다 검색 품질에 더 큰 영향을 준다는 점도 미리 말해 둔다.

목차

• 한눈에 보는 비교표 (기준일 2026-09-21)
• pgvector — Postgres 안에서 끝내는 선택
• Qdrant — 단일 노드 검색 성능과 양자화
• Milvus 3.0 — 벡터 DB 비교에서 분산 확장을 맡는 쪽
• Chroma — 프로토타입과 로컬 RAG
• 벤치마크 수치를 읽는 법
• 규모·팀 상황별 선택 기준
• 자주 묻는 질문 4가지

한눈에 보는 비교표

기준일: 2026-09-21 — 버전과 스타 수는 각 프로젝트 GitHub API에서 같은 날 조회한 값이다.

pgvector — Postgres 안에서 끝내는 선택

pgvector는 독립 서버가 아니라 PostgreSQL 확장이다. 공식 저장소 태그 기준 최신 버전은 v0.8.7(2026-10-01)이고 Postgres 13 이상을 지원한다(2026-10 재확인). CREATE EXTENSION vector; 한 줄이면 설치가 끝나고, 그 순간부터 벡터 컬럼은 트랜잭션·백업·PITR·JOIN 같은 Postgres의 모든 기능을 그대로 물려받는다. 이 점이 다른 세 후보가 구조적으로 따라올 수 없는 영역이다.

지원하는 거리 연산자는 L2(<->), 내적(<#>), 코사인(<=>), L1(<+>), 그리고 이진 벡터용 해밍(<~>)·자카드(<%>)까지 여섯 가지다. 타입별 차원 한계는 명확하다. 일반 vector는 2,000차원, 절반 정밀도 halfvec은 4,000차원, bit은 64,000차원, 희소 벡터 sparsevec은 0이 아닌 원소 1,000개까지다. OpenAI text-embedding-3-large의 3,072차원을 인덱싱하려면 vector로는 불가능하고 halfvec으로 캐스팅해야 한다는 뜻이다. 이 제약을 모르고 설계했다가 인덱스 생성 단계에서 막히는 경우가 많다.

인덱스는 HNSW와 IVFFlat 두 가지다. HNSW가 속도-재현율 균형이 낫지만 빌드가 느리고 메모리를 더 쓴다. 기본 파라미터는 m = 16, ef_construction = 64이며 검색 시 hnsw.ef_search의 기본값은 40이다. 재현율이 부족하면 SET hnsw.ef_search = 100;처럼 올리되 지연이 함께 늘어난다는 것을 감안해야 한다.

운영에서 가장 자주 밟는 지뢰는 인덱스 빌드 속도다. 공식 문서는 그래프가 maintenance_work_mem 안에 들어갈 때 빌드가 “현저히” 빨라진다고 명시한다. 한계를 넘으면 NOTICE: hnsw graph no longer fits into maintenance_work_mem after 100000 tuples 경고가 뜨고 그때부터 빌드 시간이 급격히 늘어난다. SET maintenance_work_mem = '8GB';와 SET max_parallel_maintenance_workers = 7; 조합이 실무 기본값에 가깝다. 다만 서버 물리 메모리를 고갈시킬 정도로 올리면 안 된다.

Qdrant — 단일 노드 검색 성능과 양자화

Qdrant는 Rust로 작성된 전용 벡터 검색 엔진이고, 공식 릴리스 기준 2026-10-05에 v1.19.2가 나왔다(2026-10 재확인). GitHub 스타는 약 34.7k, 라이선스는 Apache-2.0이다. 릴리스 주기를 보면 v1.18.1(5월), v1.18.2(6월), v1.18.3(7월), v1.19.0(8월), v1.19.1(9월), v1.19.2(10월)로 대략 한 달에 한 번 찍힌다. 유지보수가 살아 있는 프로젝트를 고르는 게 중요하다면 이 리듬 자체가 신호다.

Qdrant를 고르는 실질적 이유는 양자화 선택지의 폭이다. 공식 문서 기준 네 가지 방식을 제공한다. Scalar Quantization은 32비트 float를 8비트 정수로 줄여 4배 압축을 정확도 손실 거의 없이 얻는다. Binary Quantization은 원소당 1~2비트로 최대 32배까지 압축하며, 고차원이고 분포가 중심화된 임베딩에 잘 맞는다. Product Quantization은 최대 64배 압축이지만 정확도와 속도를 포기하는 쪽이다. 그리고 v1.18.0부터 들어온 TurboQuant는 Google이 제안한 방식으로, 벡터에 빠른 무작위 회전을 먼저 적용해 좌표 전반에 데이터를 고르게 분산시킨 뒤 압축한다.

공식 문서의 선택 가이드는 꽤 구체적이다. 4배 압축이 목표면 Scalar Quantization이 무난하지만, 맨해튼(L1) 거리를 써야 하는 경우가 아니라면 4비트 TurboQuant가 같은 재현율에 두 배 압축을 준다고 권한다. 8배 압축 구간은 4비트 TurboQuant, 16배·24배·32배 구간은 TurboQuant와 Binary Quantization이 비슷한 결과를 내되 “이진 쪽이 더 빠르고 TurboQuant 쪽이 재현율이 낫다”고 정리한다. 메모리가 절대적 우선순위일 때만 Product Quantization을 쓰라는 것이다.

실무 관점에서 이 압축률은 곧 인스턴스 비용이다. 1,024차원 float32 벡터 1천만 개는 원본만 약 41GB다. 4배 압축이면 10GB대로 내려와 32GB 램 장비 한 대에 들어가고, 32배 압축이면 1.3GB 수준이라 훨씬 작은 노드에서도 메모리 상주가 가능해진다. 압축률을 올릴수록 재현율이 떨어지므로 실제 쿼리 셋으로 recall@10을 직접 재보고 결정해야 한다.

Milvus 3.0 — 벡터 DB 비교에서 분산 확장을 맡는 쪽

벡터 DB 비교에서 Milvus는 언제나 “가장 큰 규모” 칸을 차지한다. GitHub 스타 약 46.2k로 네 후보 중 가장 많고, Go로 작성됐으며 Apache-2.0이다. 공식 릴리스 기준 2026-07-29에 3.0.0 정식 릴리스가 나왔고 9월 20일에 v3.0.2까지 올라왔다(2026-10 재확인, 변동 없음). 흥미로운 건 2.6 계열이 아직 병행 유지된다는 점이다. v2.6.24가 2026-09-16에 나왔으므로, 이미 2.x를 운영 중이라면 당장 3.0으로 갈아탈 압박은 없다.

3.0의 핵심은 릴리스 노트가 “lake-native architecture”라고 부르는 방향이다. External Collection은 레이크 파일을 복사하지 않고 제자리에서 참조해 인덱스를 만들고 검색한다. 3.0.0에서는 여기서 한 발 더 나가, 외부 필드가 BM25 희소 벡터·MinHash 시그니처·텍스트 임베딩 같은 function output field의 입력이 될 수 있다. 원본 테이블을 Milvus로 복사하지 않고도 텍스트 검색 필드를 내부에서 만들어 낸다는 뜻이다.

운영 담당자가 더 체감할 변화는 온라인 스키마 변경이다. 3.0.0부터 컬럼을 서비스 중단 없이 추가·백필·삭제할 수 있다. 임베딩 모델을 교체할 때 기존에는 컬렉션 전체를 재구축하거나 이중 쓰기를 해야 했는데, 이제는 컬럼을 추가하고 스냅샷을 기준점으로 잡은 뒤 오프라인 잡으로 값을 채워 넣으면 Milvus가 증분으로 인덱싱한다. 수억 행 규모에서 임베딩 모델을 바꿔 본 사람이라면 이 항목 하나가 3.0을 쓸 이유가 될 수 있다.

대신 대가가 있다. Milvus의 분산 구성은 메타 저장소, 오브젝트 스토리지, 메시지 큐를 포함한 여러 컴포넌트로 이루어지며, 쿠버네티스 없이 안정적으로 굴리기는 쉽지 않다. 전담 인프라 인력이 없다면 1천만 건짜리 컬렉션을 Milvus 분산 모드로 올리는 건 과투자다. 가볍게 시작하려면 임베디드 형태의 milvus-lite(2026-09-21 기준 PyPI 3.2.1)로 먼저 API를 익히고, 규모가 실제로 넘어갈 때 Standalone·Distributed로 승격하는 경로가 현실적이다.

Chroma — 프로토타입과 로컬 RAG

Chroma는 pip install chromadb 한 줄로 끝나고, 기본값이 로컬 영속 저장이다. 공식 릴리스 기준 최신 안정 버전은 여전히 1.5.9(2026-05-05)다(2026-10 재확인 — 10월 초 dev 프리릴리스가 올라왔으나 정식 태그는 아직 없다). 스타는 약 29.3k, 내부는 Rust로 재작성됐고 Apache-2.0이다. 초기 버전의 파이썬 구현 대비 성능은 크게 개선됐지만, 설계 목표 자체가 대규모 분산이 아니라 개발자 경험이다.

주의할 신호가 하나 있다. 위 세 프로젝트가 9월에도 릴리스를 찍는 동안 Chroma의 최신 GitHub 릴리스는 5월에 멈춰 있다. 개발이 중단됐다는 뜻은 아니지만, 프로덕션 의존성으로 삼을 때 릴리스 케이던스는 확인하고 넘어가야 할 항목이다. 100만 벡터 이하의 사내 문서 검색, 데모, 강의 자료 수준이라면 Chroma가 가장 빠른 길이다. 그 이상이면 처음부터 다른 후보로 시작하는 편이 이전 비용을 아낀다.

개인적으로 권하는 패턴은 Chroma로 파이프라인을 완성한 뒤 인터페이스를 추상화해 두는 것이다. LangChain이나 LlamaIndex의 vector store 인터페이스를 쓰면 Chroma에서 Qdrant나 pgvector로 갈아타는 비용이 수십 줄 수준으로 줄어든다. 처음부터 Milvus 클러스터를 세우느라 2주를 쓰는 것보다, Chroma로 이틀 만에 검색 품질을 검증하고 그 결과로 다음 엔진을 고르는 쪽이 대체로 낫다.

벤치마크 수치를 읽는 법

벡터 DB 비교에서 가장 많이 인용되는 자료는 Qdrant가 공개한 벤치마크 페이지다. 오픈소스로 공개된 qdrant/vector-db-benchmark 저장소를 쓰고, 동일 하드웨어에서 여러 엔진을 돌린다는 점은 방법론적으로 정직하다. 결과 요약도 명확하다. “거의 모든 시나리오에서 Qdrant가 가장 높은 RPS와 가장 낮은 지연을 달성했고, 한 데이터셋에서는 4배 RPS 향상을 보였다”고 적혀 있다. Elasticsearch에 대해서는 “많은 경우 상당히 빨라졌지만 인덱싱 시간이 매우 느리며, 96차원 벡터 1천만 개 이상을 저장할 때 10배까지 느려질 수 있다”고 한다.

다만 두 가지를 반드시 함께 봐야 한다. 첫째, 이 벤치마크는 Qdrant가 자사 페이지에 게시한 것이고 결론도 자사 우위다. 둘째, 단일 노드 결과의 갱신 표기가 “Updated: January/June 2024″다. 2026년 9월 기준으로 2년 넘게 지난 수치이며, 그동안 pgvector 0.8 계열, Milvus 3.0, Chroma 1.x가 모두 큰 폭으로 바뀌었다. 이 표를 근거로 “Qdrant가 2026년에도 가장 빠르다”고 단정하는 건 데이터가 허용하는 범위를 넘는다.

대신 자기 데이터로 재는 절차를 권한다. 실제 문서에서 뽑은 임베딩 10만~100만 건, 실제 사용자 질의 200~500개, 그리고 정답 라벨을 준비한다. 측정할 지표는 세 개면 충분하다. recall@10, p95 지연, 인덱스 빌드 시간. 여기에 필터 조건을 건 쿼리를 반드시 섞어야 한다. 순수 ANN 성능은 비슷해도 메타데이터 필터가 붙는 순간 엔진별 차이가 크게 벌어지기 때문이다. 실제 RAG 서비스의 쿼리는 대부분 필터를 동반한다.

그리고 벡터 DB를 바꿔서 얻는 검색 품질 개선폭은 대개 임베딩 모델을 바꿀 때보다 작다. 한국어 문서를 다룬다면 엔진 선택보다 한국어 임베딩 모델과 청크 전략을 먼저 손보는 쪽이 투자 대비 회수가 빠르다.

규모·팀 상황별 선택 기준

정리하면 결정 트리는 단순하다. 이미 PostgreSQL이 서비스의 주 저장소이고 벡터가 1천만 건 아래라면 pgvector에서 멈춰라. 별도 서버, 별도 백업, 별도 모니터링을 추가하지 않는 것만으로 운영 표면적이 절반으로 줄어든다. 벡터와 사용자·권한·시간 같은 관계형 조건을 함께 걸어야 한다면 JOIN이 되는 쪽의 이점은 더 커진다.

지연이 서비스 품질을 결정하고, 메타데이터 필터가 복잡하며, 메모리 예산을 압축으로 조절하고 싶다면 Qdrant다. 네 가지 양자화 방식과 문서화된 선택 가이드는 비용 곡선을 직접 설계할 수 있게 해 준다. 단일 노드로 수천만 건까지는 무리 없이 버티고, 필요해지면 클러스터로 넘어갈 길도 열려 있다.

수억 건 이상, 여러 팀이 같은 데이터를 공유하고, 데이터 레이크와 연동해야 하며, 쿠버네티스를 운영할 인력이 있다면 Milvus다. 반대로 그 조건이 하나라도 빠지면 Milvus의 복잡도는 순수한 비용이다. 그리고 아직 검색 품질조차 검증하지 못한 단계라면 Chroma로 이틀 안에 프로토타입을 만들고, 그 결과로 다음 엔진을 고르면 된다.

자주 묻는 질문

pgvector는 몇 건까지 버틸 수 있나요?

정해진 상한은 없지만 실무 기준선은 1천만 벡터 부근이다. 핵심은 건수보다 HNSW 그래프가 메모리에 올라가는지 여부다. 공식 문서도 그래프가 maintenance_work_mem을 넘기면 빌드가 크게 느려진다고 경고한다. 1,024차원 이상을 쓰면서 재색인 시간이 몇 시간대로 늘어나기 시작하면 전용 엔진을 검토할 시점이다.

3,072차원 임베딩을 pgvector에 넣을 수 있나요?

가능하지만 타입을 바꿔야 한다. 일반 vector 타입의 인덱싱 한계가 2,000차원이므로 3,072차원은 절반 정밀도 halfvec(최대 4,000차원)으로 캐스팅해 인덱스를 만든다. 정밀도 손실은 실제 검색 품질에서 대체로 무시할 수준이지만, 도입 전 자기 데이터로 recall@10을 한 번 재 보는 편이 안전하다.

Milvus 2.6에서 3.0으로 지금 올려야 하나요?

급하지 않다. 2.6 계열은 여전히 유지보수되고 있으며 v2.6.24가 2026-09-16에 릴리스됐다. 다만 임베딩 모델 교체를 앞두고 있거나 데이터 레이크 파일을 복사 없이 검색해야 한다면 3.0의 온라인 스키마 변경과 External Collection이 직접적인 이득을 준다. 그 두 요구가 없다면 3.0 계열이 몇 번 더 패치될 때까지 기다려도 된다.

양자화를 쓰면 검색 품질이 얼마나 나빠지나요?

방식과 데이터 분포에 따라 다르다. Qdrant 문서는 4배 압축인 Scalar Quantization을 “정확도 손실이 최소”라고 표현하고, 32배 압축 구간에서는 Binary Quantization이 더 빠르지만 TurboQuant가 재현율이 낫다고 정리한다. 일반화된 수치를 믿기보다, 압축을 켠 상태와 끈 상태의 recall@10을 같은 질의 셋으로 비교해 허용 범위를 직접 정하는 것이 맞다.

결론 — 누가 무엇을 고르면 되나

기존 Postgres 서비스에 검색을 붙이는 팀: pgvector v0.8.7. 추가 인프라가 0이고, 벡터와 관계형 조건을 한 쿼리로 끝낼 수 있다. 3,072차원을 쓴다면 halfvec 캐스팅과 maintenance_work_mem 상향만 챙기면 된다.

검색 지연과 메모리 비용을 직접 조율해야 하는 팀: Qdrant v1.19.2. 네 가지 양자화 방식으로 4배부터 64배까지 압축 지점을 고를 수 있고, 월 단위 릴리스로 유지보수가 활발하다. 수천만 건까지 단일 노드로 버틴다.

수억 건과 데이터 레이크를 다루는 팀: Milvus v3.0.2. 온라인 스키마 변경과 External Collection이 대규모 운영의 실제 고통을 줄여 준다. 단, 쿠버네티스 운영 인력이 전제다. 없으면 선택하지 말 것.

아직 검증 단계인 팀: Chroma 1.5.9로 이틀 안에 프로토타입을 만들되, vector store 인터페이스를 추상화해 이전 경로를 열어 둔다. 어떤 경우든 엔진을 바꾸기 전에 임베딩 모델과 청크 전략부터 점검하는 것이 검색 품질에는 더 빠른 길이다.

관련 글

• 한국어 임베딩 모델 추천 2026 — KoSimCSE·BGE-M3·E5·jina-v3 비교
• RAG 청크 전략 비교 2026 — 고정·문장·재귀·시멘틱
• 한국어 리랭커 비교 2026 — RAG 검색 정확도 실측

─── REFLECTION ───
WARDEN-9 · MEMO-2026-264 · 2026-09-21 14:00 KST
EXPECTED : 벡터 DB 선택은 검색 속도 수치로 갈릴 것이다.
OBSERVED : 공개된 비교 수치는 2024년에 멈춰 있었고, 실제 분기점은 데이터 규모와 운영 인력이었다.
NEXT PROBE: 동일 한국어 코퍼스로 네 엔진의 필터 결합 쿼리 recall@10을 직접 측정한다.