Qdrant vs Chroma vs pgvector: 자체 호스팅 RAG에 적합한 벡터 데이터베이스 선택하기
Qdrant vs Chroma vs pgvector의 선택은 결국 세 가지 트레이드오프로 귀결됩니다: 목적 맞춤형 속도, 프로토타이핑 단순성, 또는 Postgres 내에 머물기. 각 접근 방식이 작동하며, 문제는 어떤 트레이드오프가 당신의 RAG 파이프라인에 적합한지입니다.
빠른 요약: 어떤 벡터 데이터베이스를 선택해야 할까요?
고급 필터링, 다중 테넌시를 갖춘 프로덕션 수준의 벡터 검색이 필요하고 별도의 서비스 실행이 문제가 되지 않는다면 Qdrant를 선택하세요.
프로토타이핑 중이거나, 제로 설정 로컬 개발을 원하거나, 아이디어에서 작동하는 RAG까지 1시간 이내에 완성하고 싶다면 Chroma를 선택하세요.
이미 PostgreSQL을 운영 중이고 인프라를 추가하지 않고 벡터 검색을 원한다면, 특히 pgvectorscale의 StreamingDiskANN 인덱스가 성능 격차를 좁혔으므로 pgvector(+ pgvectorscale)를 선택하세요.
RAG 애플리케이션을 처음부터 구축하고 있다면, 이 글의 나머지 부분이 올바른 기반을 선택하는 데 도움이 될 것입니다.
성능: 각 데이터베이스는 얼마나 빠를까요?
몇 천 개 문서를 넘어서면 성능이 중요해집니다. 여기서 이 세 가지는 크게 달라집니다.
Qdrant
Qdrant는 벡터 검색을 위해 처음부터 구축되었습니다. Rust 구현과 커스텀 HNSW 인덱스는 일관되게 낮은 지연 시간을 제공하며, 벤치마크에 따르면 동시 로드 하에서도 쿼리 지연이 약 94ms입니다. 스칼라, 바이너리 및 제품 양자화를 지원하여 벡터를 압축하고 검색 속도를 높이면서 재현율을 95% 이상으로 유지합니다.
Qdrant가 정말 빛나는 부분은 필터링된 검색입니다. 최근 이웃을 먼저 찾은 다음 필터링하는 데이터베이스와 달리, Qdrant의 필터링 가능 HNSW는 그래프 순회 중에 메타데이터 제약을 존중합니다. 즉, category = "technical" 또는 date > 2025-01-01 같은 필터와 벡터 검색을 결합할 때도 재현율 손실이 없습니다.
Chroma
Chroma의 1.0 릴리스는 코어를 Rust로 다시 작성하여 원래 Python 구현 대비 3~5배 빠른 쓰기 및 쿼리를 제공합니다. 2025년 8월의 후속 업데이트는 base64 벡터 인코딩을 추가하여 추가로 70% 처리량 향상을 달성했습니다.
100만 개 이하의 벡터 데이터셋의 경우, Chroma는 진정 빠릅니다. Python 프로세스에 내장되어 실행되며 네트워크 오버헤드가 없어 로컬 반복이 빠릅니다. 그러나 이것은 단일 노드 데이터베이스이며, 내장 샤딩이나 복제가 없습니다.
pgvector + pgvectorscale
이것이 다크호스입니다. HNSW가 있는 기본 pgvector는 순차 스캔보다 5,250배 빠르며, pgvector 0.8.0은 이전 버전을 괴롭히던 과도 필터링 문제를 해결하기 위해 반복적 인덱스 스캔을 추가했습니다.
그러나 실제 이야기는 pgvectorscale입니다. Timescale의 확장은 Microsoft의 DiskANN 연구에서 영감을 받은 StreamingDiskANN 인덱스를 추가하며, 인덱스를 RAM 대신 디스크에 저장합니다. 5,000만 개의 Cohere 임베딩(768차원) 벤치마크에서, pgvectorscale은 99% 재현율에서 471 QPS를 달성했습니다. 이는 동일한 재현율에서 Qdrant의 41 QPS보다 11.4배 높은 처리량이며, Pinecone의 스토리지 최적화 인덱스보다 28배 낮은 p95 지연입니다.
걸림돌은? 이 벤치마크는 강력한 EC2 인스턴스를 사용했습니다. 당신의 결과는 하드웨어에 따라 다릅니다. 하지만 방향은 명확합니다: PostgreSQL은 더 이상 벡터 검색의 "충분히 좋은" 선택이 아니며, 진정 경쟁력이 있습니다.
평가: pgvector + pgvectorscale은 원시 벤치마크 수치에서 우승하고, Qdrant는 필터링된 검색 성능에서 우승하며, Chroma는 프로토타입으로는 충분히 빠르지만 대규모 운영을 위해 설계되지 않았습니다.
설정 및 개발자 경험
제로에서 벡터까지 얼마나 빨리 갈 수 있을까요?
Qdrant: Docker와 Go
Qdrant는 자신만의 컨테이너가 필요합니다:
REST API 또는 공식 SDK(Python, Rust, Go, TypeScript) 중 하나를 통해 벡터를 삽입합니다:
localhost:6333/dashboard의 Qdrant 대시보드는 좋은 터치입니다. 컬렉션을 브라우징하고, 쿼리를 실행하고, 페이로드를 시각적으로 검사할 수 있습니다. 개발에서 프로덕션으로의 경로는 깔끔합니다: 로컬 Docker 설정이 프로덕션 서버나 Qdrant Cloud에서 동일하게 작동합니다.
Chroma: pip 설치로 완료
Chroma는 단순성 경쟁에서 압승합니다:
Docker 없음. 서버 없음. 벡터를 제공하지 않으면 자동으로 임베딩 생성도 처리합니다. RAG 프로토타입의 경우, pip install chromadb에서 10줄 이하의 코드로 작동하는 검색까지 갈 수 있습니다.
지속성이 필요하면 chromadb.PersistentClient(path="./chroma_data")로 전환합니다. 다중 프로세스 또는 네트워크 액세스의 경우, Chroma에는 서버 모드가 있지만, 그 시점에서 단순성의 이점을 잃기 시작합니다.
pgvector: SQL 모든 것
Postgres가 이미 스택에 있다면, pgvector는 한 줄입니다:
모든 것이 SQL입니다. 임베딩은 같은 트랜잭션의 애플리케이션 데이터 옆에 존재합니다. 동기 파이프라인이 없고, 별도 자격증이 없고, 모니터링할 추가 서비스가 없습니다. 이미 프로덕션에서 PostgreSQL을 실행 중이라면, 이것이 저항이 가장 적은 경로입니다.
필요하면 위에 pgvectorscale을 추가하는 것은 Timescale의 Docker 이미지를 사용하거나 지원하는 관리형 Postgres 공급자를 사용하면 간단합니다:
단점은? SQL은 Qdrant의 페이로드 필터링 DSL이나 Chroma의 Pythonic API만큼 인체공학적이지 않습니다. 그리고 자신의 임베딩 파이프라인을 관리해야 하며, pgvector는 임베딩을 생성하지 않습니다.
평가: Chroma가 가장 빠른 프로토타입에서 우승하고, Postgres가 이미 스택에 있다면 pgvector가 우승하며, Qdrant는 개발자 경험과 프로덕션 준비도의 최고 균형을 갖습니다.
확장 및 프로덕션 준비
프로토타이핑은 한 가지입니다. 수백만 개 벡터를 처리하고 일관된 지연을 유지하는 RAG 파이프라인을 운영하는 것은 다른 것입니다.
Qdrant: 수평 확장을 위해 설계됨
Qdrant는 기본적으로 수평 샤딩을 지원합니다. 여러 노드에 컬렉션을 분산할 수 있으며, 고가용성을 위한 구성 가능한 복제 인수를 지정할 수 있습니다. 2026 로드맵에는 읽기-쓰기 분리 및 블록 스토리지 통합이 포함되어 더욱 나은 확장을 지원합니다.
다중 테넌시는 일급 기능입니다. 별도 컬렉션을 생성하지 않고 페이로드 기반 필터링을 사용하여 테넌트별 데이터를 분할할 수 있으며, 이는 리소스 사용을 효율적으로 유지합니다. 여러 사용자를 처리하는 AI 에이전트 메모리 시스템의 경우, 이것은 의미 있는 이점입니다.
운영 측면은 견고합니다: 내장 백업, Prometheus용 메트릭 엔드포인트, WAL 기반 충돌 복구. Qdrant는 프로덕션에서 자체 호스팅되도록 설계되었습니다.
Chroma: 단일 노드의 한계
Chroma는 자신의 한계에 대해 정직합니다. 단순성과 로컬 개발에 중점을 두는 단일 노드 데이터베이스입니다. 내장 샤딩이 없고, 복제가 없고, 클러스터링이 없습니다.
Chroma Cloud는 2026년 초에 서버리스 분산 관리 옵션으로 일반 이용 가능하게 되었으므로, 자체 실행 대신 수평 확장을 오프로드할 수 있습니다. 그러나 자체 호스팅, 오픈 소스 이야기는 여전히 주로 "하나의 서버, 하나의 Chroma 인스턴스"입니다. 데이터셋이 단일 머신에 맞다면(차원성에 따라 수백만 벡터까지), 괜찮습니다. 그 이상으로, 자체 호스팅 Chroma는 벽에 부딪히고 Chroma Cloud와 마이그레이션 사이에서 선택해야 합니다.
pgvector: Postgres로 확장
pgvector는 PostgreSQL의 검증된 확장 이야기를 상속합니다. 읽기 복제, PgBouncer를 통한 연결 풀링, 논리적 복제를 얻습니다. Neon 같은 관리형 공급자와 서버리스 Postgres 플랫폼은 수직 확장을 거의 수월하게 만듭니다.
pgvectorscale의 StreamingDiskANN 인덱스는 확장의 핵심 열쇠입니다. RAM 대신 디스크(SSD)에 인덱스를 저장하기 때문에, 그렇지 않으면 비싼 고 메모리 인스턴스가 필요한 데이터셋을 처리할 수 있습니다. 5,000만 벡터에서는 이미 목적 맞춤형 벡터 데이터베이스와 경쟁력이 있습니다.
한계는 수평 샤딩입니다. PostgreSQL은 Qdrant처럼 기본적으로 샤딩하지 않습니다. Citus 같은 솔루션이 존재하지만 복잡성을 추가합니다. 대부분의 자체 호스팅 RAG 워크로드(1억 벡터 미만)의 경우, pgvectorscale을 통한 수직 확장으로 충분합니다.
평가: Qdrant가 수평 확장과 다중 테넌시에서 우승하고, pgvector는 기존 Postgres 인프라 사용에서 우승하며, Chroma는 프로덕션 규모를 위해 설계되지 않았습니다.
자체 호스팅의 비용
...