RAG 파이프라인 구축하실 때 벡터DB 고르는 게 은근히 고민되실 텐데요, 이번엔 가격 산정 방식부터 지연 시간, 실제 프로덕션 벤치마크까지 여러 소스를 교차 확인해서 정리했어요. 먼저 핵심 비교부터 표로 보여드릴게요.
한눈에 보는 비교표
| 항목 | Pinecone | Qdrant |
| 서비스 형태 | 완전관리형 전용 (셀프호스팅 불가) | 오픈소스, 셀프호스팅 + 클라우드 |
| 개발 언어 | 비공개 독자 아키텍처 | 러스트 |
| 과금 방식 | 쓰기유닛(WU) + 읽기유닛(RU) + 저장용량 종량제 | 클러스터 리소스(RAM·vCPU·디스크) 기반 정액제 |
| 무료 티어 | 있음 (소규모, 사용량 제한) | 1GB 클러스터 무료, 시간 제한 없음 |
| 지연 시간 (일반적 범위) | 서버리스 45~80ms, 팟 기반 20~40ms | 인메모리 15~30ms, 메모리맵 30~60ms |
| 필터링 성능 | 후처리 방식 | HNSW 그래프 탐색에 필터 통합 |
| 인프라 관리 | 불필요 (완전 추상화) | 셀프호스팅 시 직접 관리 필요 |
| 비용 우위 구간 | 쿼리 빈도가 낮은 워크로드 | 쿼리 빈도가 높거나(하루 15,000건 이상) 필터링 중심 워크로드 |
이 표만 봐도 두 서비스의 근본적인 차이가 보이실 텐데요, 아래에서 왜 이런 차이가 나는지, 그리고 실제 비용이 규모에 따라 어떻게 갈리는지 좀 더 풀어드릴게요.
두 서비스의 기본 철학이 달라요
Pinecone은 완전관리형 벡터DB예요. 벡터를 넣고 쿼리로 꺼내오기만 하면 되고, 인프라 관리가 전혀 필요 없어요. 아키텍처 자체가 사용자에게 완전히 추상화돼 있고, AWS·GCP·애저 리전에서 Pinecone의 클라우드 환경 안에서만 동작해요. 대신 HNSW 인덱스 파라미터를 직접 튜닝할 수 없다는 제약이 있어요.
Qdrant는 러스트로 작성된 오픈소스 벡터DB예요. 단일 노드 배포부터 분산 클러스터, Qdrant 클라우드까지 여러 배포 옵션을 제공해요. 특히 메타데이터 필터링을 HNSW 그래프 탐색 과정 안에서 처리하는 방식이라, 필터가 많이 걸리는 쿼리에서 강점을 보인다는 평가가 여러 출처에서 공통적으로 나와요. Pinecone은 반대로 필터링을 후처리 방식으로 적용하는 구조라, 복잡한 필터 조건이 걸릴수록 Qdrant와의 격차가 벌어지는 경향이 있어요.
지연 시간은 조건에 따라 다르지만, 대략적인 범위는 겹쳐요
여러 벤치마크를 종합해보면 Pinecone은 서버리스 기준 45~80ms, 팟 기반 전용 인덱스 기준으로는 20~40ms 정도가 일반적으로 언급되는 범위예요. Qdrant는 인메모리 인덱스 기준 15~30ms, 디스크에 걸쳐 메모리맵으로 서빙할 때는 30~60ms 정도로 보고돼요.
Qdrant 팀이 직접 밝힌 공식 프로덕션 벤치마크로는 1억 3,500만 개 벡터를 초당 600쿼리로 처리했을 때 P50 지연 시간 45ms, P99 96ms를 기록한 사례가 있고, 14억 개 벡터 규모의 고객 사례에서는 초당 5,700쿼리에 P99 60ms를 기록했다고 해요.
다만 이 숫자들을 절대적인 기준으로 삼으시면 안 돼요. Qdrant 팀이 레딧의 한 벤치마크 스레드에 직접 남긴 코멘트를 보면, 정밀도(recall)를 같이 측정하지 않은 순수 처리량 비교는 의미가 없다는 지적이 있었어요. 정밀도를 낮추면 처리량은 얼마든지 올릴 수 있기 때문에, 어느 벤치마크를 보시든 recall@k 수치가 같이 명시돼 있는지부터 확인하시는 게 좋아요.
비용 구조가 완전히 달라서 규모에 따라 승자가 바뀌어요
Pinecone의 과금 방식은 쓰기유닛(WU)과 읽기유닛(RU), 저장 용량을 조합한 종량제예요. 여기서 중요한 함정이 하나 있는데, 읽기유닛이 반환되는 결과 수가 아니라 스캔한 네임스페이스 크기를 기준으로 과금된다는 점이에요.
그러니까 top_k를 1로 설정하든 100으로 설정하든, 50GB 네임스페이스를 스캔하면 50 RU가 그대로 청구돼요. 이 때문에 쿼리 빈도가 높은 워크로드, 특히 에이전트가 매 스텝마다 벡터 검색을 호출하는 구조에서는 계산기로 예상한 비용보다 실제 청구액이 훨씬 크게 나오는 경우가 많다는 지적이 여러 소스에서 공통적으로 나와요.
Qdrant 클라우드는 반대로 클러스터에 할당한 RAM, vCPU, 디스크 리소스를 시간 단위로 과금하는 방식이에요. 그러니까 하루에 10만 건을 쿼리하든 500만 건을 쿼리하든, 같은 클러스터 리소스를 쓰는 한 비용이 동일해요.
이 구조 때문에 여러 출처에서 공통적으로 언급되는 손익분기점이 있는데, 5백만 벡터 규모 기준으로 하루 쿼리 수가 약 1만 5천 건을 넘어서면 Qdrant 쪽이 확실히 저렴해지기 시작한다는 분석이에요. 규모가 더 커져서 5천만 벡터를 넘어가면 Qdrant 클라우드가 Pinecone 대비 30% 이상 저렴해진다는 사례 분석도 있었고요. 셀프호스팅까지 고려하시면 격차는 더 벌어져서, 1억 벡터 규모에서 Qdrant를 직접 서버에 셀프호스팅하면 월 50~100달러 수준까지 내려간다는 사례도 있어요. 물론 이건 운영 인력 투입 비용은 뺀 순수 인프라 비용이라는 점은 감안하셔야 해요.
실전: 기본 CRUD 비교
두 서비스 다 SDK를 통해 비슷한 방식으로 벡터를 넣고 검색할 수 있어요. 아래는 파이썬 기준 Qdrant에 벡터를 저장하고 필터링 쿼리를 날리는 기본 코드예요.
from qdrant_client import QdrantClient
from qdrant_client.models import PointStruct, VectorParams, Distance
client = QdrantClient(url="http://localhost:6333")
client.create_collection(
collection_name="docs",
vectors_config=VectorParams(size=1536, distance=Distance.COSINE)
)
client.upsert(
collection_name="docs",
points=[PointStruct(id=1, vector=[0.1] * 1536, payload={"tenant_id": "a"})]
)
results = client.search(
collection_name="docs",
query_vector=[0.1] * 1536,
query_filter={"must": [{"key": "tenant_id", "match": {"value": "a"}}]},
limit=5
)
여기서 query_filter로 넘긴 조건이 벡터 검색 과정 자체에 녹아드는 게 Qdrant의 핵심 강점이에요. 멀티테넌트 환경에서 특정 테넌트 데이터만 검색해야 하는 상황이라면 이 방식이 후처리 필터링보다 훨씬 효율적으로 동작해요.
정리하면
결국 선택 기준은 팀의 운영 역량과 워크로드 성격이에요. 인프라를 아예 신경 쓰고 싶지 않고 쿼리 빈도가 낮은 초기 단계라면 Pinecone이 맞고, 어느 정도 도커나 쿠버네티스 운영 경험이 있고 쿼리 빈도가 높거나 비용 대비 성능을 최적화하고 싶다면 Qdrant가 유리해요.
특히 메타데이터 필터링이 워크로드의 중심이거나(멀티테넌트 SaaS, 특정 카테고리 검색 등), 에이전트 루프처럼 쓰기·읽기가 빈번하게 반복되는 구조라면 Qdrant 쪽 손을 들어주는 자료가 확실히 많았어요. 어느 쪽이든 도입 전에는 본인 데이터 규모와 실제 쿼리 패턴(특히 하루 쿼리 횟수)을 그대로 재현한 비용 시뮬레이션을 직접 돌려보시고 결정하시는 게 제일 정확해요.