필사 모드: 벡터 데이터베이스 2026 완벽 가이드 - Pinecone · Weaviate · Qdrant · Milvus · pgvector · LanceDB · Chroma · FAISS · DiskANN 심층 분석

들어가며 — 2026년 5월, 벡터 DB는 "범용 인프라"가 됐다

2023년만 해도 벡터 데이터베이스는 "RAG를 만들고 싶은데 어디에 임베딩을 넣어야 하지?"라는 질문에 답하는 신생 카테고리였다. 2026년 5월 현재 그 질문은 끝났다. RAG는 성숙했고, 벡터 검색은 어떤 OLTP/OLAP DB에도 기본 옵션처럼 들어갔으며, 하이브리드 검색(BM25 + dense vector + 리랭커)이 표준이 됐다.

이 글은 마케팅 매트릭스가 아니라 "지금 프로덕션에서 어떤 벡터 DB가 어떤 자리에 들어가는지"를 정직하게 짚는다. Pinecone Serverless v3, Weaviate 1.30, Qdrant 1.13, Milvus 2.5 + Zilliz Cloud, Chroma, LanceDB, pgvector 0.8 + pgvectorscale 0.6 + ParadeDB, Vespa, OpenSearch k-NN, Redis Vector, MongoDB Atlas Vector, Couchbase, SingleStore, Turbopuffer, Marqo, Vald, NGT, FAISS, ScaNN, DiskANN, Annoy, DuckDB VSS, sqlite-vec, jina HnswLib 사용까지 실제 API와 함께 비교한다.

벡터 DB 2026 지형 — 5개 트랙으로 분해하기

먼저 큰 그림이다. 2026년 벡터 DB 시장은 다음 5개 트랙으로 분리됐다.

1. **순수 벡터 DB(pure-play)**: Pinecone, Weaviate, Qdrant, Milvus, Chroma, LanceDB, Turbopuffer, Marqo

2. **관계형 DB의 벡터 확장**: pgvector + pgvectorscale, ParadeDB, SingleStore, Oracle 23ai, SQL Server 2025

3. **검색 엔진의 벡터 확장**: Elasticsearch dense_vector, OpenSearch k-NN, Vespa, Solr

4. **다목적 NoSQL의 벡터 확장**: MongoDB Atlas Vector, Redis Vector, Couchbase, DynamoDB(2025년 GA)

5. **임베디드/라이브러리**: FAISS, ScaNN, DiskANN, Annoy, NGT, HnswLib, Vald, DuckDB VSS, sqlite-vec

같은 ANN 알고리즘(HNSW가 압도적 다수)을 쓰면서도 운영 모델, 가격, 멀티테넌시, 하이브리드 검색 지원에서 크게 갈린다. 아래부터 한 트랙씩 본다.

ANN 알고리즘 1 — HNSW가 사실상 표준이 된 이유

ANN(Approximate Nearest Neighbor) 알고리즘의 2026년 표준은 **HNSW(Hierarchical Navigable Small World)** 다. Yu. Malkov 와 D. Yashunin의 2016년 논문에서 출발했고, 다층 그래프 위에서 그리디 탐색을 한다.

- **레이어 0**: 모든 노드. 가장 조밀한 이웃 연결.

- **상위 레이어**: 노드 일부를 확률적으로 승격. 점점 듬성듬성해진다.

- **탐색**: 상위 레이어에서 시작해 가까운 노드로 내려간다. 각 레이어에서 `ef` 후보 큐를 유지.

장점은 **삽입/삭제/탐색이 모두 그래프 기반**이라 동적 데이터에 강하다는 점이고, 단점은 **메모리 점유**가 크다는 점이다. 1억 개 768차원 float32 벡터 + HNSW(M=16)는 대략 350GB 메모리를 먹는다.

Pinecone, Weaviate, Qdrant, Milvus, pgvector 0.8, Elasticsearch, OpenSearch, Redis, Chroma, LanceDB, Vespa 모두 HNSW를 기본 또는 옵션으로 제공한다.

ANN 알고리즘 2 — IVF · IVF-PQ · DiskANN · ScaNN의 자리

HNSW가 표준이라지만, 다른 알고리즘도 살아 있다.

- **IVF(Inverted File Index)**: k-means 로 공간을 `nlist` 셀로 분할 후, 쿼리에서 `nprobe` 셀만 본다. Milvus와 FAISS의 클래식 옵션.

- **IVF-PQ**: IVF + Product Quantization. 벡터를 PQ 코드로 압축해 메모리를 1/8 ~ 1/32로 줄인다. 10억 벡터 이상 스케일에서 필수.

- **DiskANN**(Microsoft Research): NVMe SSD 친화 그래프 인덱스. 10억 벡터를 단일 장비에서 서빙. pgvectorscale의 StreamingDiskANN이 이걸 차용.

- **ScaNN**(Google): asymmetric quantization + tree 결합. TensorFlow 친화. 정확도/속도 곡선이 매우 우수.

- **Annoy**(Spotify): random projection forest. 메모리 매핑 친화. 정적 인덱스에 적합.

- **NGT**(Yahoo Japan): ONNG 그래프. Vald 클러스터의 코어.

선택 가이드를 단순화하면 다음과 같다.

- **1천만 벡터 미만, 동적 갱신**: HNSW

- **1억 이상, 메모리 한계**: IVF-PQ 또는 DiskANN

- **읽기 전용 대규모**: ScaNN, Annoy

리콜 vs 레이턴시 vs 비용 — ann-benchmarks의 현실

ann-benchmarks.com 의 2026년 5월 데이터를 압축하면 다음과 같다. 동일 GIST-960-1M 데이터셋에서:

- HNSW(M=16, ef=200): recall@10 0.99, p99 1.2ms, 메모리 4GB

- IVF-PQ(nlist=4096, nprobe=64, m=32): recall@10 0.93, p99 0.9ms, 메모리 0.5GB

- DiskANN(R=64, L=100): recall@10 0.98, p99 4ms, 메모리 1GB + SSD

- ScaNN(reorder=200): recall@10 0.99, p99 0.6ms, 메모리 3GB

요점은 "공짜 점심은 없다"는 것이다. 리콜을 0.95에서 0.99로 끌어올리는 데 일반적으로 레이턴시는 2 ~ 5배, 메모리는 1.5 ~ 3배 든다. 프로덕션에선 `recall@10 = 0.95` 가 충분한 경우가 많다.

Pinecone Serverless v3 — 매니지드의 디폴트

Pinecone은 2024년 1월 Serverless GA, 2025년 4분기 v3 라인업으로 **storage/compute 완전 분리**를 완성했다. 2026년 5월 기준 가장 "그냥 쓰면 되는" 매니지드 옵션이다.

- 인덱스 생성 시 dimension, metric(cosine/dotproduct/euclidean), cloud(aws/gcp/azure), region만 지정.

- 백엔드는 자체 ANN(HNSW 변형 + 파티셔닝). 사용자에게는 노출 안 함.

- 가격은 **저장량 + 읽기 단위(RU) + 쓰기 단위(WU)** 셋. 콜드 인덱스는 비용이 거의 0에 가까움.

- 멀티 테넌시는 **namespace** 단위. namespace 당 격리된 인덱스 + RU 카운팅.

- 2025년부터 sparse vector(BM25) + dense vector 하이브리드 1급 지원.

- 2026년 1분기 ColBERT-style late interaction 베타.

전형적 Python 사용은 다음과 같다.

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="pc-...")

pc.create_index(

name="rag-prod-2026",

dimension=1024,

metric="cosine",

spec=ServerlessSpec(cloud="aws", region="us-east-1"),

)

index = pc.Index("rag-prod-2026")

index.upsert(

vectors=[

{"id": "doc-1", "values": [0.01] * 1024, "metadata": {"tenant": "acme", "lang": "ko"}},

],

namespace="tenant-acme",

)

result = index.query(

vector=[0.01] * 1024,

top_k=10,

namespace="tenant-acme",

filter={"lang": {"$eq": "ko"}},

include_metadata=True,

)

Pinecone의 가장 큰 강점은 "운영 부담 0"이고, 단점은 가격 예측이 어렵다는 것이다. RU/WU 단위 과금이라 워크로드가 폭증하면 청구서가 따라 폭증한다.

Qdrant — Rust 기반 셀프호스팅 챔피언

Qdrant는 Rust로 작성된 OSS 벡터 DB로, 셀프호스팅 트랙에서 가장 인기 있다. 2026년 5월 기준 1.13 라인업의 특징은 다음과 같다.

- **HNSW + scalar/product quantization**(int8, binary, PQ) 결합. binary quant + reorder로 디스크/메모리를 4 ~ 32배 절약.

- **Payload 인덱스**: keyword, integer, float, geo, full-text, datetime 인덱스를 자체적으로 만든다. pre-filter 시 사실상 RDB처럼 동작.

- **Sparse vector + dense vector 동시 검색** + RRF/DBSF 융합.

- **Multi-vector**(ColBERT 등 late interaction) 1급 지원.

- **Distributed cluster**(샤딩 + Raft)와 Qdrant Cloud 매니지드 둘 다 제공.

컬렉션 생성과 쿼리 예는 다음과 같다.

from qdrant_client import QdrantClient

from qdrant_client.models import (

Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue,

)

client = QdrantClient(url="http://qdrant:6333", api_key="q-...")

client.create_collection(

collection_name="rag_prod",

vectors_config=VectorParams(size=1024, distance=Distance.COSINE),

)

client.upsert(

collection_name="rag_prod",

points=[PointStruct(id=1, vector=[0.01] * 1024, payload={"lang": "ko", "tenant": "acme"})],

)

hits = client.search(

collection_name="rag_prod",

query_vector=[0.01] * 1024,

query_filter=Filter(must=[FieldCondition(key="lang", match=MatchValue(value="ko"))]),

limit=10,

)

Qdrant Cloud는 GCP/AWS/Azure에 매니지드를 제공하며, 가격은 메모리/디스크 기반이라 Pinecone 보다 예측 가능하다. 셀프호스팅도 Helm chart로 가능해 K8s 친화적이다.

Weaviate — 모듈 + 하이브리드의 강자

Weaviate는 Go로 작성된 OSS 벡터 DB로, **모듈 시스템**과 **하이브리드 검색 1급 지원**이 강점이다. 2026년 5월 1.30 라인업 기준:

- **모듈**: text2vec-openai, text2vec-cohere, text2vec-jina, multi2vec-clip, generative-openai, reranker-cohere 등. 임베딩 생성을 DB 안에서 해결.

- **Hybrid search**: BM25 + dense + Reciprocal Rank Fusion 한 줄로.

- **Multi-tenancy**: 테넌트마다 별도 인덱스 디렉토리. 수만 ~ 수십만 테넌트 친화.

- **Weaviate Cloud Services(WCS)**: 매니지드. Hybrid Cloud(BYOC) 옵션도 2025년 4분기 GA.

- **Generative 검색**: 검색 결과를 LLM에 바로 넘겨 RAG 응답을 받는 한 줄 API.

스키마 생성과 하이브리드 검색 예다.

from weaviate.classes.config import Configure, Property, DataType

client = weaviate.connect_to_local()

client.collections.create(

name="Doc",

properties=[

Property(name="content", data_type=DataType.TEXT),

Property(name="lang", data_type=DataType.TEXT),

],

vectorizer_config=Configure.Vectorizer.text2vec_openai(model="text-embedding-3-large"),

generative_config=Configure.Generative.openai(model="gpt-4.1-mini"),

)

docs = client.collections.get("Doc")

result = docs.query.hybrid(

query="벡터 데이터베이스 비교",

alpha=0.5,

limit=10,

)

Weaviate의 강점은 "임베딩 + 검색 + 생성"을 한 시스템에서 끝낼 수 있다는 것이다. 단점은 모듈 의존성이 복잡해 셀프호스팅 시 운영 비용이 늘어난다는 점.

Milvus 2.5 + Zilliz Cloud — 대규모 + GPU의 챔피언

Milvus는 LF AI & Data Foundation 산하의 대규모 벡터 DB로, 십억 ~ 백억 벡터 스케일에서 가장 검증됐다. 2026년 5월 2.5 라인업:

- **분산 아키텍처**: query node, data node, index node, coord 분리. K8s 친화.

- **인덱스 옵션**: HNSW, IVF, IVF-PQ, DiskANN, GPU-CAGRA, GPU-IVF-PQ.

- **GPU 인덱싱**: NVIDIA cuVS / RAFT 기반 GPU-CAGRA. CPU 대비 10 ~ 100배 처리량.

- **하이브리드 검색**: BM25 + dense + RRF, 다중 벡터 필드, partition_key 기반 멀티 테넌시.

- **Zilliz Cloud**: Milvus 제작사가 운영하는 매니지드. AWS/GCP/Azure 전 리전.

컬렉션 생성과 하이브리드 검색 예는 다음과 같다.

from pymilvus import MilvusClient, DataType

client = MilvusClient(uri="http://milvus:19530", token="root:Milvus")

schema = client.create_schema()

schema.add_field("id", DataType.INT64, is_primary=True, auto_id=True)

schema.add_field("dense", DataType.FLOAT_VECTOR, dim=1024)

schema.add_field("sparse", DataType.SPARSE_FLOAT_VECTOR)

schema.add_field("tenant", DataType.VARCHAR, max_length=64)

idx = client.prepare_index_params()

idx.add_index("dense", index_type="HNSW", metric_type="COSINE", params={"M": 16, "efConstruction": 200})

idx.add_index("sparse", index_type="SPARSE_INVERTED_INDEX", metric_type="IP")

client.create_collection("rag", schema=schema, index_params=idx)

Milvus는 "엔터프라이즈 대규모"가 정체성이다. 1억 미만 워크로드라면 오히려 운영 부담이 크니, Pinecone/Qdrant/Weaviate 가 낫다.

pgvector + pgvectorscale + ParadeDB — Postgres가 "충분히 좋다"는 진영

2026년의 흥미로운 흐름은 **Postgres + pgvector**가 "특별한 요구가 없으면 충분히 좋다"는 디폴트로 자리잡은 것이다.

- **pgvector 0.8**: HNSW + IVFFlat 인덱스. 2025년 binary quantization, halfvec(16비트) 추가.

- **pgvectorscale 0.6**(Timescale): StreamingDiskANN 인덱스 + statistical binary quantization. pgvector 보다 10 ~ 100배 빠른 필터 검색.

- **ParadeDB**: Postgres 위에 BM25(`pg_search`) + 벡터를 결합. 하이브리드 검색을 Postgres 안에서 끝낸다.

- **Supabase, Neon, Aurora, Cloud SQL**: 모두 pgvector 기본 설치.

전형적 사용은 다음과 같다.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE EXTENSION IF NOT EXISTS vectorscale;

CREATE TABLE doc (

id bigserial PRIMARY KEY,

tenant_id uuid NOT NULL,

content text NOT NULL,

embedding vector(1024) NOT NULL

);

CREATE INDEX ON doc USING diskann (embedding vector_cosine_ops);

CREATE INDEX ON doc (tenant_id);

SELECT id, content, 1 - (embedding <=> $1) AS score

FROM doc

WHERE tenant_id = $2

ORDER BY embedding <=> $1

LIMIT 10;

장점은 **트랜잭션 + JOIN + 권한 + 백업**이 그냥 Postgres와 같다는 점이다. 단점은 1억 벡터 이상에서 HNSW 메모리 압박이 심하고, 멀티테넌시를 RLS로 풀면 인덱스 효율이 떨어진다는 점.

Chroma · LanceDB — 임베디드/로컬 트랙

프로덕션 단일 노드 또는 노트북에서 RAG 프로토타입을 만들 때 가장 흔히 쓰이는 두 도구.

- **Chroma**: Python/JS 우선. 단일 프로세스 임베디드, 또는 HTTP 서버. SQLite + DuckDB + HNSWLib 조합. 2026년 1분기 distributed 모드 베타.

- **LanceDB**: Rust로 작성. Apache Arrow + Lance 파일 포맷 기반. S3/GCS 위에 그대로 올려도 동작. 임베디드 + 서버 모두 가능. multimodal 친화.

LanceDB의 매력은 "S3에 .lance 파일 하나로 끝낸다"는 점이다. 매니지드도 따로 없지만 LanceDB Cloud(베타)와 SageMaker 통합 옵션이 늘고 있다.

db = lancedb.connect("s3://my-bucket/lance-db")

tbl = db.create_table(

"docs",

data=[{"id": 1, "vector": [0.01] * 1024, "lang": "ko"}],

mode="overwrite",

)

tbl.create_index(metric="cosine", index_type="IVF_HNSW_SQ", num_partitions=256)

hits = tbl.search([0.01] * 1024).where("lang = 'ko'").limit(10).to_list()

Elasticsearch · OpenSearch · Vespa — 검색 엔진 트랙

기존 BM25 검색 엔진이 dense vector를 본격 지원하면서, 별도 벡터 DB를 도입하지 않고 같은 클러스터에서 하이브리드 검색을 하는 흐름이 자리잡았다.

- **Elasticsearch 8.x ~ 9.x**: `dense_vector` 필드 + HNSW. `_search` 안에 `knn` + `query`(BM25) 결합으로 하이브리드. ELSER(Elastic Learned Sparse Encoder)로 sparse vector도 자체 제공.

- **OpenSearch 2.x ~ 3.x**: `knn` 플러그인. FAISS/Lucene/NMSLib 백엔드 선택. AWS OpenSearch Service에서 매니지드.

- **Vespa**: Yahoo가 만들고 오픈소스로 푼 검색 엔진. tensor 표현이 1급. multi-vector, 멀티 스테이지 랭킹이 강점. Spotify Discover Weekly, Yahoo Mail이 사용.

기존 검색 클러스터가 있는 조직이 가장 먼저 시도하는 경로다. 단점은 벡터 전용 DB만큼 인덱싱 처리량/메모리 효율이 좋지는 않다는 점.

NoSQL의 벡터 확장 — Mongo · Redis · Couchbase · SingleStore · DuckDB · SQLite

운영 데이터가 이미 들어 있는 DB가 벡터를 지원하면 운영이 가장 단순해진다.

- **MongoDB Atlas Vector Search**: Atlas의 전용 검색 인덱스(Lucene 기반). `$vectorSearch` aggregation 단계.

- **Redis 8 Vector Search**: HNSW + flat. Redis Stack/Redis Enterprise. 인-메모리라 ms 미만 응답.

- **Couchbase Vector Search**: 2024년 GA. SQL++ 안에서 벡터 쿼리.

- **SingleStore**: 분산 SQL DB + 벡터. 분석/검색/트랜잭션 한 클러스터.

- **DuckDB VSS 확장**: in-process 분석 + HNSW. 데이터프레임/Parquet에 그대로 인덱스.

- **sqlite-vec**: Alex Garcia가 만든 SQLite 확장. 모바일/엣지 RAG 용.

이 트랙의 공통점은 "벡터를 위해 별도 클러스터를 만들지 않는다"는 점이다. 1억 벡터 미만, 본업이 OLTP인 서비스라면 가장 합리적인 선택이 된다.

신흥 트랙 — Turbopuffer · Marqo · Vald · NGT · Tair Vector

매니지드/특화 시장에서도 신규 진입자가 늘었다.

- **Turbopuffer**: S3 위에 올린 서버리스 벡터 DB. 가격이 매우 낮고(스토리지 + 쿼리당 과금), 콜드 데이터에 강하다. 2025년 Notion이 채택해 주목받음.

- **Marqo**: 임베딩 + 검색을 한 묶음으로 제공. multimodal 친화. cloud + 셀프호스팅.

- **Vald**(Yahoo Japan/LY): K8s 네이티브, NGT 기반 분산 벡터 DB. LINE 검색에 사용.

- **NGT**(Yahoo Japan): 그래프 기반 ANN 라이브러리. ONNG, PANNG, QG 변형.

- **Tair Vector**(Alibaba Cloud): Redis 호환 + 벡터. 중국 시장 디폴트.

FAISS · ScaNN · DiskANN · Annoy · HnswLib — 라이브러리 트랙

DB가 아니라 라이브러리로 직접 인덱스를 다루는 트랙이다. 학습/연구나 임베디드에서 여전히 핵심.

- **FAISS**(Meta): C++/Python. IVF, HNSW, IVF-PQ, GPU FAISS. Meta 내부 + 학계 디폴트.

- **ScaNN**(Google): TensorFlow 친화. asymmetric quantization. 정확도/속도 비율 우수.

- **DiskANN**(Microsoft): SSD 친화 그래프. pgvectorscale, Milvus가 차용.

- **Annoy**(Spotify): random projection. 메모리 매핑. 정적 인덱스에 적합.

- **HnswLib**: hnsw 알고리즘 저자가 만든 단순한 HNSW 라이브러리. Chroma, Jina, Weaviate 초기 백엔드.

- **NGT**(Yahoo Japan): 그래프 기반. 일본/한국에서 채택 사례 많음.

라이브러리 직접 사용 예(FAISS):

d = 1024

nb = 100000

xb = np.random.random((nb, d)).astype("float32")

xq = np.random.random((1, d)).astype("float32")

index = faiss.IndexHNSWFlat(d, 32)

index.hnsw.efConstruction = 200

index.add(xb)

index.hnsw.efSearch = 64

D, I = index.search(xq, 10)

print(I, D)

하이브리드 검색 — BM25 + dense + RRF + Reranker가 표준이 된 이유

2024년 이후 명확해진 사실은 **dense vector 하나만으로는 부족하다**는 것이다. 키워드(이름, ID, 코드) 매칭에 약하고, OOD(out-of-domain) 쿼리에서 무너지기 쉽다. 2026년 표준은 다음 4단계 파이프라인이다.

1. **BM25 검색**(sparse)으로 top-50 ~ 100

2. **Dense vector 검색**으로 top-50 ~ 100

3. **RRF(Reciprocal Rank Fusion)** 또는 가중 합으로 후보 100 ~ 200 정리

4. **Reranker**(Cohere Rerank 3.5, Voyage Reranker 2, BGE Reranker v2-m3, Jina Reranker v2)로 top-10

RRF 가중 식은 단순하다.

def rrf(rankings: list[list[str]], k: int = 60) -> dict[str, float]:

scores: dict[str, float] = {}

for ranking in rankings:

for rank, doc_id in enumerate(ranking, start=1):

scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)

return scores

리랭커는 cross-encoder 구조로 쿼리와 문서 쌍을 동시에 본다. 검색 점수 대비 NDCG@10이 5 ~ 15% 오르는 게 일반적이다. Cohere Rerank 3.5는 100개 문서 리랭킹에 약 80ms, 가격은 1,000 쿼리당 $2 수준이다.

멀티벡터와 ColBERT · ColPali — 새로운 정확도 표준

문서 하나를 단일 벡터로 압축하면 디테일이 사라진다. 그래서 등장한 게 **멀티벡터(multi-vector)** 접근이다.

- **ColBERT v2**(Stanford 2022 → 2024년 PLAID 최적화): 문서 토큰별 벡터를 다 저장 + 쿼리 토큰과 late interaction(MaxSim). dense single-vector 대비 NDCG가 크게 좋음.

- **ColPali**(2024): 비전 트랜스포머로 페이지 이미지를 패치 벡터 다발로 임베딩. PDF/슬라이드 RAG에 혁신적.

- **ColQwen2**: ColPali의 Qwen2-VL 백본 버전.

문제는 저장량이다. 토큰당 벡터를 저장하면 데이터셋이 50 ~ 200배 커진다. Qdrant, Vespa, Weaviate, ParadeDB 가 멀티벡터를 네이티브로 지원하고, Pinecone은 2026년 1분기 베타 단계다.

필터 검색 — pre-filter vs post-filter, 그리고 메타데이터 인덱스

벡터 검색은 거의 항상 메타데이터 필터와 함께 쓴다("tenant_id = X AND lang = ko").

- **Post-filter**: ANN 검색 후 필터. 후보 부족 위험.

- **Pre-filter**: 필터 먼저 적용 후 ANN. Qdrant/Weaviate/Milvus/pgvector가 잘 한다.

- **Indexed filter**: 메타데이터 자체에 인덱스를 만들어 결합 검색.

Pinecone, Weaviate, Qdrant, Milvus, Elasticsearch는 메타데이터 인덱스를 자체로 만든다. pgvector는 Postgres B-tree/GIN 인덱스에 의존. 멀티테넌시가 큰 워크로드라면 pre-filter 성능을 항상 벤치마크해야 한다.

임베딩 모델 선택 — OpenAI vs Cohere vs Voyage vs BGE vs E5 vs Jina

벡터 DB만 잘 골라도 임베딩이 나쁘면 검색 품질은 무너진다. 2026년 5월 MTEB 리더보드 상위권은 다음과 같다.

- **OpenAI text-embedding-3-large**(3072d, matryoshka 256/1024/3072). 균형 좋음.

- **Cohere Embed v4**(1024d, 멀티모달, 멀티링구얼, matryoshka).

- **Voyage 3 / Voyage 3-large**(1024d, 도메인 특화 + 일반 우수).

- **BGE-M3**(1024d, dense + sparse + ColBERT 동시 출력, OSS).

- **E5-Mistral-7B-instruct**(4096d, OSS).

- **gte-Qwen2-7B-instruct**(3584d, OSS).

- **Jina Embeddings v3**(1024d, multilingual, late chunking 지원).

선택 기준은 (1) 멀티링구얼이 필요한지, (2) matryoshka로 차원 축소가 필요한지, (3) 셀프호스팅이 필요한지, (4) 비용을 어디까지 받아들이는지다. 한국어/일본어 환경에서는 BGE-M3, Cohere v4, Jina v3, multilingual-e5-large가 안전한 선택이다.

RAG-specific 패턴 — chunking · contextual retrieval · parent-child

벡터 DB 위에 RAG를 올릴 때 2026년 표준 패턴은 다음과 같다.

- **Chunking**: 토큰 300 ~ 800 + 50 토큰 오버랩이 가장 흔하다. 의미 기반 분할(semantic chunking)도 인기.

- **Contextual retrieval**(Anthropic 2024 발표): 청크마다 "이 청크는 어떤 문서의 어디인가"를 LLM이 짧게 쓰게 해 임베딩 전에 prepend. 검색 실패율을 절반 가까이 줄임.

- **Parent-child**: 작은 청크로 검색, 부모 청크/문서를 LLM에 넘긴다.

- **Query expansion**: HyDE(가상 응답 생성 후 임베딩), multi-query, query rewriting.

- **Reranking**: top-100 → top-10 cross-encoder 리랭킹은 거의 모든 RAG에서 권장.

이 패턴은 DB와 무관하지만, 멀티벡터/sparse 지원 여부가 어떤 패턴을 쉽게 쓸 수 있는지를 결정한다.

GPU 벡터 인덱싱 — RAFT · cuVS · NVIDIA 가속

NVIDIA RAPIDS의 **cuVS**(RAFT의 후속)가 2025년 GA되면서 GPU 벡터 인덱싱이 본격화됐다.

- **CAGRA**: GPU 친화 그래프 ANN. HNSW 대비 빌드는 10배 이상 빠르고 쿼리도 GPU에서 5 ~ 50배 빠름.

- **GPU IVF-PQ**: 십억 벡터 인덱스 빌드를 시간 단위에서 분 단위로 단축.

- **Milvus** GPU CAGRA, **FAISS** GPU 모듈, **RAPIDS cuVS**가 채택. Pinecone, Weaviate, Qdrant는 GPU를 코어로 쓰지는 않음(쿼리 시 CPU가 보편).

학습이 아니라 검색 단계에서도 GPU가 의미 있어지는 변곡점이 2025 ~ 2026년이다. 다만 비용 구조상 단일 노드 1억 벡터 미만이라면 CPU + HNSW 가 여전히 우월하다.

비용 경제학 — Pinecone vs Weaviate Cloud vs 셀프호스팅 Qdrant

대략적인 가격 비교(2026년 5월, 1억 벡터 1024d, p50 50ms 타깃).

- **Pinecone Serverless**: 약 $2,500 ~ $4,000/월(저장 + 평균 트래픽).

- **Weaviate Cloud(Serverless)**: 약 $2,000 ~ $3,500/월.

- **Zilliz Cloud(Milvus)**: 약 $1,500 ~ $3,000/월.

- **Qdrant Cloud**: 약 $1,200 ~ $2,500/월.

- **Turbopuffer**: 약 $300 ~ $800/월(콜드 워크로드).

- **셀프호스팅 Qdrant on K8s**(EKS, 4 x r6i.2xlarge): 약 $1,200/월 인프라 + 운영 인력.

- **셀프호스팅 pgvector**(Aurora Serverless v2): 약 $700 ~ $1,500/월.

가격은 트래픽 패턴에 따라 4 ~ 10배까지 갈라진다. 콜드 RAG라면 Turbopuffer/pgvector가 우월하고, 항상 따끈한 트래픽이면 셀프호스팅 Qdrant가 가장 싸진다.

한국 도입 사례 — Naver, Kakao, Toss, 당근

한국 IT 시장의 2026년 5월 벡터 DB 현황은 다음과 같다.

- **Naver Clova**: 자체 HyperCLOVA X RAG 인프라. Milvus 변형 + 자체 임베딩으로 추정.

- **Kakao Brain**: pgvector + 자체 임베딩 모델로 KoGPT 응용 RAG.

- **Toss**: 검색팀이 Vespa 기반 멀티스테이지 랭킹 구축. 벡터는 사내 인덱스.

- **당근**: 마켓플레이스 추천에 Faiss + 자체 임베딩. Qdrant 적용 사례 발표.

- **삼성SDS, LG CNS**: 사내 RAG에 Pinecone 또는 Weaviate 매니지드 사용 사례.

- **스타트업 챗봇/검색 도메인**: Qdrant, Weaviate, pgvector가 가장 흔함.

한국어 임베딩은 BGE-M3, Cohere Embed v4, multilingual-e5-large가 사실상 표준 후보다. 한국어 특화 모델(KoSimCSE 등)은 도메인이 좁을 때 강점이 있다.

일본 도입 사례 — Vald(LY), NGT(Yahoo), Mercari, LINE 검색

- **Yahoo Japan / LY Corporation**: NGT 라이브러리 개발, Vald 분산 벡터 DB OSS. LINE 검색/추천에 사용.

- **Mercari**: 시맨틱 검색에 Elasticsearch + 자체 임베딩, 그리고 일부 워크로드에 Vespa.

- **CyberAgent**: 광고 추천에 Faiss 기반 자체 시스템.

- **Rakuten**: 상품 검색에 Solr/Elastic + 자체 임베딩 결합.

- **Preferred Networks**: 사내 RAG에 Qdrant 도입 사례 발표.

NGT는 한국에서도 알려진 라이브러리지만, Vald 클러스터를 직접 돌리는 사례는 일본 내에서도 LY/네이버 등 일부에 한정된다. Mercari의 Vespa 도입은 검색 도메인에서 자주 인용된다.

의사결정 가이드 — 워크로드별 추천

마지막으로 워크로드별 추천을 단순화한다.

- **노트북/단일 노드 RAG 프로토타입**: Chroma, LanceDB, DuckDB VSS, sqlite-vec

- **모놀리식 SaaS, 1억 벡터 미만, Postgres 운영 중**: pgvector + pgvectorscale (+ ParadeDB)

- **K8s 셀프호스팅, 1억 ~ 10억 벡터**: Qdrant, Weaviate, Milvus

- **운영 부담 최소화 매니지드**: Pinecone Serverless, Qdrant Cloud, Zilliz Cloud, Weaviate Cloud

- **10억 벡터 초과, GPU 인덱싱 필요**: Milvus GPU(CAGRA), Vespa, 자체 FAISS 인프라

- **콜드 워크로드, 가격 최적화**: Turbopuffer, pgvector, LanceDB on S3

- **검색 클러스터가 이미 있다**: Elasticsearch dense_vector, OpenSearch k-NN, Vespa

- **OLTP DB 위에서 끝낸다**: MongoDB Atlas Vector, Redis Vector, Couchbase, SingleStore

- **임베디드/모바일**: sqlite-vec, LanceDB embedded

- **하이브리드 검색 + 리랭킹 1급 지원이 필요**: Qdrant, Weaviate, Vespa, Milvus, ParadeDB

- **멀티벡터(ColBERT/ColPali) 1급 지원**: Qdrant, Vespa, Weaviate, ParadeDB

"기본값을 정해 두고 예외만 옮긴다"는 원칙을 적용하면, 2026년 5월 기준 새 RAG의 디폴트는 **(A) Postgres + pgvector + pgvectorscale** 또는 **(B) Qdrant 매니지드**가 가장 안전하다.

References

- [Pinecone](https://www.pinecone.io/) — Serverless v3 매니지드 벡터 DB

- [Weaviate](https://weaviate.io/) — 모듈 + 하이브리드 + 생성 검색

- [Qdrant](https://qdrant.tech/) — Rust 기반 OSS 벡터 DB

- [Milvus](https://milvus.io/) — 대규모 분산 벡터 DB

- [Zilliz Cloud](https://zilliz.com/cloud) — Milvus 매니지드

- [Chroma](https://www.trychroma.com/) — 임베디드 벡터 DB

- [LanceDB](https://lancedb.com/) — Arrow 기반 멀티모달 벡터 DB

- [pgvector](https://github.com/pgvector/pgvector) — Postgres 벡터 확장

- [pgvectorscale](https://github.com/timescale/pgvectorscale) — StreamingDiskANN

- [ParadeDB](https://www.paradedb.com/) — Postgres BM25 + 벡터

- [Vespa](https://vespa.ai/) — Yahoo 검색 엔진

- [OpenSearch k-NN](https://opensearch.org/docs/latest/search-plugins/knn/) — k-NN 플러그인

- [Elasticsearch dense_vector](https://www.elastic.co/guide/en/elasticsearch/reference/current/dense-vector.html) — 벡터 검색

- [Redis Vector Search](https://redis.io/docs/latest/develop/interact/search-and-query/advanced-concepts/vectors/) — 인메모리 벡터 검색

- [MongoDB Atlas Vector Search](https://www.mongodb.com/products/platform/atlas-vector-search) — Atlas 벡터 검색

- [Turbopuffer](https://turbopuffer.com/) — S3 위 서버리스 벡터 DB

- [Marqo](https://www.marqo.ai/) — 임베딩 + 검색

- [Vald](https://vald.vdaas.org/) — Yahoo Japan 분산 벡터 DB

- [NGT](https://github.com/yahoojapan/NGT) — Yahoo Japan 그래프 ANN

- [FAISS](https://github.com/facebookresearch/faiss) — Meta 벡터 라이브러리

- [DiskANN](https://github.com/microsoft/DiskANN) — Microsoft SSD 그래프 인덱스

- [ScaNN](https://github.com/google-research/google-research/tree/master/scann) — Google ANN

- [Annoy](https://github.com/spotify/annoy) — Spotify 정적 ANN

- [HnswLib](https://github.com/nmslib/hnswlib) — HNSW 참조 구현

- [Cohere Rerank](https://cohere.com/rerank) — Rerank 3.5 리랭커

- [Voyage Reranker](https://docs.voyageai.com/docs/reranker) — Voyage Reranker 2

- [MTEB Leaderboard](https://huggingface.co/spaces/mteb/leaderboard) — 임베딩 벤치마크

- [ann-benchmarks](https://ann-benchmarks.com/) — ANN 알고리즘 벤치마크

- [ColBERT](https://github.com/stanford-futuredata/ColBERT) — late interaction

- [ColPali](https://github.com/illuin-tech/colpali) — 비전 멀티벡터

- [Anthropic Contextual Retrieval](https://www.anthropic.com/news/contextual-retrieval) — 청크 컨텍스트화