벡터 데이터베이스 쇼룸 시리즈의 대단원

벡터 데이터베이스 쇼룸 시리즈의 마지막 편입니다.

6개 파트를 거치며 이 쇼룸은 여러분에게 약속했습니다. 어떤 데이터베이스를 선택해야 할지 알려주지는 않겠지만, 여러분 스스로 무엇을 선택해야 하는지 알아낼 수 있는 방법을 제시하겠다고 말이죠. 오늘로 쇼룸이 문을 닫습니다: 하나의 표, 하나의 트리, 그리고 하나의 체크리스트가 남았습니다.

참여작들을 다시 한번 소개합니다: 🚙 pgvector, 🛴 Chroma, 🏎️ Qdrant, 🚐 Weaviate, 🚕 Pinecone, 🚄 Milvus — 스테이션 왜건, 스쿠터, 해치백, 크로스오버, 택시, 그리고 기차입니다.

소유 비용(The cost-of-ownership) 표

• 즉시 사용 가능한 하이브리드 검색(Hybrid search out of the box): 가능 — Qdrant (밀집 벡터 + 희소 벡터, RRF/DBSF 융합), Weaviate (BM25F 내장), Milvus (내장 BM25). 불가능 — pgvector, Chroma. Pinecone: 사용자가 직접 희소 벡터를 가져와야 합니다 (Weaviate/Milvus의 내장 BM25 모델이 아닌 Qdrant 모델과 유사함) — 베팅하기 전에 반드시 문서를 확인하여 현재 상태를 점검하세요.
• 네이티브 멀티테넌시(Multi-tenancy, natively): Weaviate (테넌트 = 샤드), Pinecone (네임스페이스), Milvus (파티션 키 / 별도 데이터베이스). pgvector는 RLS로 이를 처리하며; Qdrant는 페이로드 필터링을 기대하고; Chroma는 아무것도 구성해주지 않습니다.

시리즈를 관통하는 수학적 계산: 1M × 1536차원 × 4바이트 ≈ 6 GB의 원본 벡터가 필요하며 — HNSW 그래프는 모든 벡터의 사본을 저장하므로, 인스턴스 크기를 결정하기 전에 대략 두 배로 잡아야 합니다.

Honorable mentions, 세 줄 요약: Elasticsearch/OpenSearch — 이미 사용 중인 스택이고 벡터 요구 사항이 적당할 때. Redis — 밀리초(sub-millisecond) 단위의 속도가 필요하고 이미 운영 중일 때. FAISS — 엔진이지 자동차가 아닙니다: 엄청나게 빠르지만, 차고도 없고, 서비스센터도 없고, 키도 없습니다. 이 엔진을 중심으로 자동차를 직접 만들어야 합니다.

flowchart TD
    START["벡터 검색이 필요합니다"] --> Q1{"프로토타이핑, 학습 또는 개인용 도구인가?"}
    Q1 -- "예" --> CHROMA["🛴 Chroma"]
...

트리 구조에 대한 두 가지 솔직한 참고 사항:

• 아직 Postgres를 사용하지 않나요? 여전히 트레일러(wagon)는 옵션입니다. 관리형 Postgres는 클릭 한 번 거리에 있습니다 (Part 1). 차고가 필수 조건은 아닙니다.
• 데이터가 경계를 벗어날 수 없고 게다가 운영 담당자를 원하지 않는 경우? 그것은 데이터베이스 문제가 아니라 채용 문제입니다. 이 쇼룸의 어떤 자동차도 해결해 주지 못합니다. 그리고 그렇지 않다고 가장하는 것이 바로 2주짜리 모험을 시작하게 만드는 방식입니다.

하루 만에 테스트 드라이브하기

트리에서 최종 후보 2~3개를 고르세요 — 여섯 개 모두 아닙니다. 그런 다음:

시작하기 전에

• 모든 후보를 위한 하나의 임베딩 모델을 사용하세요 — Part 3부터의 솔직한 비교 규칙입니다.
• 실제 데이터: 제품에서 나온 실제 문서 1050k개와 실제 쿼리 50100개를 준비합니다. Lorem ipsum은 lorem ipsum을 측정합니다.
• 실제로 탑승할 게이지(gauge)를 배포하세요: 만약 프로덕션 환경이 클러스터라면, 그 클러스터의 형태를 벤치마크해야 합니다 — Milvus에서 얻은 교훈입니다.

(2~3시간)

• 로드하기 전에 스키마와 페이로드/메타데이터 인덱스를 생성하세요 — Qdrant과 Milvus에서 배운 교훈입니다.
• 데이터를 로드합니다. 그리고 기다리세요: 확정된 세그먼트, 구축된 인덱스 (벤치마크 함정 #1과 #2). 신선한 데이터에 대한 벤치마크는 브루트 포스를 측정할 뿐, 인덱스가 아닙니다.

(2시간) — 점수표

Recall@10 대 정확한 실제 값(exact ground truth). 동일한 벡터를 직접 브루트 포싱 해보세요 — 50k 행의 경우 몇 초면 충분합니다:

import numpy as np

# vectors: (N, 1536)에 업로드된 임베딩들, query: (1536,)
...

• 실제 QPS에서의 p95 지연 시간 (데모 QPS가 아님)
• 인덱싱 후 RAM 사용량 — 원본 벡터의 약 2배를 예상하세요 (시리즈 규칙)
• 필터링 검색: 'similar AND year=2024'가 전체 LIMIT를 반환하는가? (Part 1 함정)
• 삽입 → 즉시 검색: 불안정한가? 이제 프로덕션에서 어떻게 작동할지 알게 되었다 (택시와 기차)
• 작업 도중 프로세스 종료 (셀프 호스팅) 또는 오류 후 재시도 테스트 (관리형) — 그리고 아무것도 손실되지 않았는지 확인하세요
• 모든 것을 다시 내보내기 — 약속이 아닌 시간 단위로 퇴장 비용을 측정하세요

(1시간) — 청구서

• 관리형 (Pinecone): 실제 QPS × top_k → 읽기 유닛 → 달러. 관리형 (Qdrant / Weaviate / Zilliz Cloud): RAM + CPU → 월별 구독료. 어느 쪽이든 미터는 잠들지 않습니다.
• 셀프 호스팅: 측정된 RAM → 들어갈 수 있는 가장 작은 인스턴스 → × 12개월
• 점수표를 채우고, 그리고 그 위에 주무세요:

네,