Wybór bazy danych wektorów: porównanie Pinecone, Qdrant, Weaviate, pgvector
Wybór niewłaściwej bazy danych wektorów dla systemu RAG może kosztować tygodnie refaktoryzacji i nieplanowany budżet. W 2026 roku rynek skonsolidował się wokół czterech głównych opcji, każdy z zupełnie innym profilem kompromisu: Szyszka dla tych, którzy chcą zarządzać obsługa bez operacji, Qdrant dla tych, dla których priorytetem jest wydajność i własny hosting, Tkać dla tych, którzy potrzebują natywnego wyszukiwania hybrydowego, np pgwektor dla tych, którzy chcą pozostać w istniejącej bazie danych PostgreSQL.
W tym przewodniku znajdziesz dane porównawcze, rzeczywiste koszty i kryteria wyboru świadomą decyzję opartą na konkretnym obciążeniu pracą.
Czego się nauczysz
- Testy porównawcze opóźnień i przepustowości dla głównych wektorowych baz danych na rok 2026
- Koszty rzeczywiste w różnych skalach (wektory 100K, 1M, 10M, 100M)
- Macierz decyzyjna: która baza danych dla jakiego przypadku użycia
- Praktyczna konfiguracja z Pythonem dla Qdrant i pgvector
- Indeksy HNSW: parametry krytyczne dla optymalnej wydajności
- Kiedy Milvus jest właściwym wyborem dla ponad 100 milionów przewoźników
Dlaczego baza danych wektorowych ma większe znaczenie niż model
W systemie RAG jakość ostatecznej odpowiedzi zależy w 60-70% od jakości wyszukiwania, nie z wybranego LLM. GPT-4o ze słabym pobieraniem będzie generować gorsze odpowiedzi niż GPT-4o-mini z doskonałym odbiorem. Baza danych wektorowych jest sercem wyszukiwania: jej opóźnieniem i precyzją i jego skalowalność decydują o doświadczeniu użytkownika w systemie.
Benchmark 2026: Rzeczywiste dane na standaryzowanym sprzęcie
Poniższe punkty odniesienia zostały zmierzone na zbiorze danych składającym się z 1 miliona wektorów z 1536 wymiarów (embedding OpenAI text-embedding-3-small), z zapytaniem k=10, na serwerze z 8 vCPU i 32GB 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 wyłania się na lidera w zakresie wydajności/własnego hostingu. Pinecone oferuje gwarantowane umowy SLA jako usługa zarządzana. pgvector z HNSW (wprowadzonym w PostgreSQL 16) został prawie całkowicie zmostkowany lukę w przypadku rozwiązań dedykowanych.
Analiza kosztów w różnych skalach
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)
Praktyczna konfiguracja: Qdrant
Qdrant jest najczęstszym wyborem dla zespołów technicznych, które chcą maksymalnej wydajności kontrolę nad wdrożeniem. Oto pełna konfiguracja:
# 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")
Praktyczna konfiguracja: pgvector
pgvector to mądry wybór, jeśli już korzystasz z PostgreSQL: zero dodatkowej infrastruktury, Transakcje ACID, DOŁĄCZ do innych tabel. Dzięki HNSW wydajność jest porównywalna z rozwiązaniami dedykowany do wag poniżej 5M przewoźników.
# 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), ...]
Matryca decyzyjna: który wybrać
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
Najczęstsze błędy w wyborze
- Wybierz pgvector z IVFFlat w zbiorach danych > 500 tys. wektorów: opóźnienie znacznie się degraduje. Użyj HNSW (dostępnego od PostgreSQL 16) lub migruj do rozwiązania poświęcony
- Przeszacowanie wielkości osadzania: osadzanie tekstu-3-małe a Wymiary 1536 mają prawie identyczną wydajność jak osadzanie tekstu-3-large przy wymiarach 3072 ale kosztuje połowę i zużywa połowę pamięci RAM
- Ignoruj ef_search w czasie zapytania: zwiększ ef_search ze 100 do 200 cali Qdrant/Weaviate poprawia przywołanie o 95% do 99% przy jedynie 1,3-krotnym narzucie opóźnienia
- Rozmiar tylko dla początkowej objętości: Najpierw zaplanuj migrację aby osiągnąć limit bieżącego wyboru
Krytyczne parametry HNSW
Indeks HNSW (Hierarchical Navigable Small World) jest sercem wydajności wektorów bazy danych. Zrozumienie jego parametrów pozwala zoptymalizować kompromis w zakresie przywracania/opóźnienia:
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)
Wnioski
Praktyczna zasada na rok 2026: w przypadku wektorów 1M często wybiera się pgvector z HNSW prawda jeśli korzystasz już z PostgreSQL — zero dodatkowej infrastruktury i wydajności konkurencyjny. Od 1 miliona do 50 milionów operatorów, Qdrant na własnym serwerze oferuje najlepszy stosunek wydajności do kosztów. Ponad 100 milionów operatorów, Milvus z rozproszonym wdrożeniem i standardowym wyborem.
Następny artykuł omawia architektury RAG — od Naive RAG po Modular RAG — wraz z kodem kompletne i wzorcowe, aby obsłużyć najbardziej złożone przypadki użycia.