ベクター データベースの選択: Pinecone、Qdrant、Weaviate、pgvector の比較
RAG システムに間違ったベクター データベースを選択すると、リファクタリングに数週間かかる可能性があります そして予定外の予算。 2026 年には、市場は 4 つの主要な選択肢を中心に統合されています。 それぞれのトレードオフ プロファイルは大きく異なります。 松ぼっくり 管理したい人向け オペレーションなしのサービス、 クドラント パフォーマンスとセルフホスティングを優先する人にとっては、 ウィアビエイト ネイティブ ハイブリッド検索が必要な場合は、e ベクター 既存の PostgreSQL データベースを使い続けたい人向け。
このガイドでは、ベンチマーク データ、実際のコスト、および選択基準を提供します。 特定のワークロードに基づいた情報に基づいた決定。
何を学ぶか
- 2026 年の主要なベクター データベースのレイテンシとスループットのベンチマーク
- さまざまなスケールでの実際のコスト (100K、1M、10M、100M ベクトル)
- 意思決定マトリックス: どのデータベースをどのユースケースに使用するか
- Qdrant および pgvector 用の Python を使用した実践的なセットアップ
- HNSW インデックス: 最適なパフォーマンスのための重要なパラメータ
- Milvus が 1 億以上の通信事業者にとって適切な選択肢となる場合
モデルよりもベクトル データベースが重要な理由
RAG システムでは、最終応答の品質は取得の品質に 60 ～ 70% 依存します。 選択した LLM からのものではありません。検索が不十分な GPT-4o は、GPT-4o-mini よりも悪い応答を生成します。 優れた検索機能を備えています。ベクトル データベースは検索の中心です: その待ち時間と精度 とその拡張性がシステムのユーザー エクスペリエンスを決定します。
ベンチマーク 2026: 標準化されたハードウェア上の実際のデータ
次のベンチマークは、1536 次元の 100 万ベクトルのデータセットで測定されました。 (OpenAI text-embedding-3-small を埋め込む)、クエリ k=10、8 vCPU と 32 GB RAM を備えたサーバー上。
Database | P50 Latency | P99 Latency | Throughput | Recall@10
-----------------|-------------|-------------|-------------|----------
Qdrant (HNSW) | 12ms | 28ms | 850 q/s | 0.989
Pinecone (cloud) | 18ms | 35ms | 600 q/s | 0.987
Weaviate (HNSW) | 22ms | 50ms | 500 q/s | 0.985
pgvector (IVFFlat)| 45ms | 120ms | 200 q/s | 0.941
pgvector (HNSW) | 18ms | 45ms | 420 q/s | 0.983
Milvus (HNSW) | 8ms | 18ms | 1200 q/s | 0.991
Note: pgvector HNSW disponibile da PG 16 (2023), molto migliorato
Qdrant はパフォーマンス/セルフホスティングのリーダーとして浮上します。 Pinecone は保証された SLA を提供します マネージドサービスとして。 pgvector と HNSW (PostgreSQL 16 で導入) はほぼ完全にブリッジされました 専用ソリューションとのギャップ。
さまざまなスケールでのコスト分析
Costo mensile stimato (USD) — 1M vettori 1536 dim, 100K query/giorno
Pinecone Starter Pod: ~$70/mese (serverless, pay-per-use)
Pinecone Standard Pod: ~$280/mese (1x p1.x1 pod, SLA garantito)
Qdrant Cloud: ~$85/mese (0.5 vCPU, 1GB RAM managed)
Qdrant Self-hosted: ~$30/mese (infrastruttura cloud VPS)
Weaviate Cloud: ~$95/mese
pgvector (in Postgres): $0 aggiuntivo (gia paghi il DB)
A 10M vettori:
Pinecone: ~$700-1400/mese
Qdrant: ~$250/mese (self-hosted con server dedicato)
pgvector: ~$50/mese aggiuntivo (RAM extra per PostgreSQL)
Milvus: ~$180/mese (self-hosted, ottimo TCO a questa scala)
A 100M+ vettori:
Pinecone: >$5000/mese
Qdrant: ~$800/mese (cluster dedicato)
Milvus: ~$500/mese (cluster distribuito on-premise)
実践的なセットアップ: Qdrant
Qdrant は、最大限のパフォーマンスを求める技術チームにとって最も一般的な選択肢です。 導入を制御します。完全なセットアップは次のとおりです。
# Qdrant: setup, indexing e querying
from qdrant_client import QdrantClient
from qdrant_client.models import (
Distance, VectorParams, HnswConfigDiff,
PointStruct, Filter, FieldCondition, MatchValue
)
from openai import OpenAI
import uuid
# Connessione (locale o cloud)
client = QdrantClient(url="http://localhost:6333")
# Per Qdrant Cloud: QdrantClient(url="...", api_key="...")
# Crea la collection con HNSW ottimizzato
client.create_collection(
collection_name="knowledge_base",
vectors_config=VectorParams(
size=1536, # dimensione embedding OpenAI
distance=Distance.COSINE
),
hnsw_config=HnswConfigDiff(
m=16, # connessioni per nodo (default: 16)
ef_construct=200, # qualita indice durante build (default: 100)
# Aumentare ef_construct migliora recall ma rallenta l'indicizzazione
),
on_disk_payload=True # payload su disco per risparmiare RAM
)
# Indicizza documenti
openai_client = OpenAI()
def embed_text(text: str) -> list[float]:
response = openai_client.embeddings.create(
input=text,
model="text-embedding-3-small"
)
return response.data[0].embedding
def index_documents(documents: list[dict]) -> None:
points = []
for doc in documents:
embedding = embed_text(doc["content"])
points.append(PointStruct(
id=str(uuid.uuid4()),
vector=embedding,
payload={
"content": doc["content"],
"source": doc["source"],
"category": doc["category"],
"created_at": doc["created_at"]
}
))
# Batch upload per efficienza
client.upsert(
collection_name="knowledge_base",
points=points,
wait=True
)
# Query con filtri
def search(
query: str,
category_filter: str | None = None,
limit: int = 5
) -> list[dict]:
query_embedding = embed_text(query)
query_filter = None
if category_filter:
query_filter = Filter(
must=[
FieldCondition(
key="category",
match=MatchValue(value=category_filter)
)
]
)
results = client.query_points(
collection_name="knowledge_base",
query=query_embedding,
query_filter=query_filter,
limit=limit,
with_payload=True
)
return [
{"content": r.payload["content"], "score": r.score, "source": r.payload["source"]}
for r in results.points
]
# Esempio d'uso
docs = [
{"content": "Come configurare l'autenticazione 2FA...", "source": "docs/security.md",
"category": "security", "created_at": "2026-01-15"},
]
index_documents(docs)
results = search("configurazione sicurezza account", category_filter="security")
実践的なセットアップ: pgvector
すでに PostgreSQL を使用している場合、pgvector は賢い選択です。追加のインフラストラクチャは必要ありません。 ACID トランザクション、他のテーブルとの JOIN。 HNSW を使用すると、ソリューションと同等のパフォーマンスが得られます 500 万キャリア未満のスケール専用。
# pgvector: schema e querying con psycopg2
import psycopg2
from pgvector.psycopg2 import register_vector
import numpy as np
conn = psycopg2.connect("postgresql://user:pass@localhost/dbname")
register_vector(conn)
with conn.cursor() as cur:
# Abilita l'estensione (una tantum)
cur.execute("CREATE EXTENSION IF NOT EXISTS vector")
# Crea la tabella con embedding
cur.execute("""
CREATE TABLE IF NOT EXISTS documents (
id BIGSERIAL PRIMARY KEY,
content TEXT NOT NULL,
source VARCHAR(500),
category VARCHAR(100),
embedding vector(1536), -- dimensione OpenAI
created_at TIMESTAMP DEFAULT NOW()
)
""")
# Crea indice HNSW (migliore performance di IVFFlat)
cur.execute("""
CREATE INDEX IF NOT EXISTS documents_embedding_hnsw_idx
ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 200)
""")
conn.commit()
# Inserimento
def insert_document(content: str, source: str, category: str, embedding: list[float]):
with conn.cursor() as cur:
cur.execute(
"INSERT INTO documents (content, source, category, embedding) VALUES (%s, %s, %s, %s)",
(content, source, category, np.array(embedding))
)
conn.commit()
# Query similarity search con filtro
def search_documents(query_embedding: list[float], category: str = None, limit: int = 5):
with conn.cursor() as cur:
if category:
cur.execute("""
SELECT content, source, 1 - (embedding <=> %s) AS similarity
FROM documents
WHERE category = %s
ORDER BY embedding <=> %s
LIMIT %s
""", (np.array(query_embedding), category, np.array(query_embedding), limit))
else:
cur.execute("""
SELECT content, source, 1 - (embedding <=> %s) AS similarity
FROM documents
ORDER BY embedding <=> %s
LIMIT %s
""", (np.array(query_embedding), np.array(query_embedding), limit))
return cur.fetchall()
# Restituisce: [(content, source, similarity_score), ...]
意思決定マトリックス: どれを選択するか
Caso d'uso | Raccomandazione | Motivo
------------------------------------|------------------------|----------------------------------
Gia uso PostgreSQL, <1M vettori | pgvector | Zero infra, JOIN nativi, ACID
Startup, MVP rapido | Pinecone Serverless | Zero ops, pay-per-use
Team tecnico, >1M vettori | Qdrant self-hosted | Best performance/cost
Hybrid search nativo necessario | Weaviate | BM25+vector integrato
>100M vettori, cluster distribuito | Milvus | Scalabilita orizzontale
Compliance (dati on-premise) | Qdrant/Milvus | Full control, nessun cloud
選択時によくある間違い
- IVFFlat で pgvector を選択する データセット > 500K ベクトル: レイテンシ 著しく劣化します。 HNSW (PostgreSQL 16 以降で利用可能) を使用するか、ソリューションに移行します 専用の
- 埋め込みのサイズを過大評価する: text-embedding-3-small a 1536 次元のパフォーマンスは、3072 次元の text-embedding-3-large とほぼ同じです。 ただし、コストは半分で、RAM の半分を使用します
- クエリ時に ef_search を無視する: ef_search を 100 から 200 に増やします。 Qdrant/Weaviate は、わずか 1.3 倍のレイテンシ オーバーヘッドで再現率を 95% ～ 99% 向上させます
- 初期ボリュームのみのサイズ: 最初に移行を計画します 現在選択している限界に達するために
HNSW の重要なパラメータ
HNSW (Hierarchical Navigable Small World) インデックスはベクター パフォーマンスの中心です データベース。そのパラメータを理解すると、リコールとレイテンシのトレードオフを最適化できます。
Parametro | Effetto sull'indice | Effetto sulla query
----------------|----------------------|--------------------
m (16-64) | Connessioni per nodo | Recall (piu alto = meglio)
| piu alto = piu RAM | Latency (marginale impatto)
| piu alto = build piu |
| lento |
| |
ef_construction | Qualita build | Nessun effetto diretto
(100-500) | piu alto = recall | (determina qualita indice)
| migliore |
| piu alto = build piu |
| lento |
| |
ef_search | Nessun effetto | Recall (molto impatto)
(50-500) | sull'indice | Latency (tradeoff principale)
Configurazione raccomandata per produzione:
- m = 16 (bilanciato), m = 32 (alta accuratezza, +50% RAM)
- ef_construct = 200 (build lenta, alta qualita indice)
- ef_search = 100-200 (aumenta a query time senza ricostruire)
結論
2026 年の経験則: 1M ベクターの下では、HNSW を備えた pgvector が選択されることがよくあります そうだよ すでに PostgreSQL を使用している場合 - 追加のインフラストラクチャとパフォーマンスは不要 競争力がある。 100 万から 5,000 万の通信事業者の間で、Qdrant セルフホスト型は最高のパフォーマンス/コスト比を提供します。 1 億を超える通信事業者、分散展開を備えた Milvus が標準的な選択肢です。
次の記事では、Naive RAG から Modular RAG まで、RAG アーキテクチャをコードとともに詳しく掘り下げます。 最も複雑なユースケースを処理するための完全なパターン。