LabHub

블로그

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

2026-05-16 · 29 분 읽기 · #vector-database#pinecone#weaviate#qdrant#milvus#pgvector#lancedb#chroma#faiss#hnsw#embeddings#rag#semantic-search#ann

한국어English日本語

들어가며 — 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년 논문에서 출발했고, 다층 그래프 위에서 그리디 탐색을 한다.

장점은 삽입/삭제/탐색이 모두 그래프 기반이라 동적 데이터에 강하다는 점이고, 단점은 메모리 점유가 크다는 점이다. 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가 표준이라지만, 다른 알고리즘도 살아 있다.

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

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

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

요점은 "공짜 점심은 없다"는 것이다. 리콜을 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월 기준 가장 "그냥 쓰면 되는" 매니지드 옵션이다.

전형적 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 라인업의 특징은 다음과 같다.

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

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 라인업 기준:

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

import weaviate
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 라인업:

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

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가 "특별한 요구가 없으면 충분히 좋다"는 디폴트로 자리잡은 것이다.

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

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 프로토타입을 만들 때 가장 흔히 쓰이는 두 도구.

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

import lancedb

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를 도입하지 않고 같은 클러스터에서 하이브리드 검색을 하는 흐름이 자리잡았다.

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

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

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

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

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

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

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

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

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

import numpy as np
import 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) 접근이다.

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

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

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

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 리더보드 상위권은 다음과 같다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

References

원문 보기: https://www.youngju.dev/blog/culture/2026-05-16-vector-databases-pinecone-weaviate-qdrant-milvus-pgvector-lancedb-chroma-faiss-2026-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다