Pro produkční RAG systémy v roce 2026 platí jednoduché pravidlo: Qdrant nabízí nejlepší poměr výkon/cena pro střední škálu, Pinecone vyhrává pro týmy bez DevOps, Weaviate excelluje v hybridním vyhledávání, Milvus škáluje na miliardy vektorů a pgvector je nejlevnější volba, pokud už PostgreSQL provozujete. Žádná z těchto vektorových databází není univerzálně „nejlepší". Výběr závisí na velikosti datasetu, latenčních požadavcích, rozpočtu a tom, zda preferujete spravovanou službu nebo self-hosting. Honestly, tohle srovnání píšu po pěti produkčních migracích za poslední rok (z Pinecone na Qdrant, z Chromy na pgvector a zpět), takže čísla níže reflektují i moje vlastní pohořelé účty.
Qdrant dosahuje nejnižší p50 latence (~4 ms na 1M vektorů @ 1536 dimenzí) mezi účelově navrženými vektorovými databázemi a vede ve filtrovaném vyhledávání.
Pinecone Serverless přidává 200–2000 ms cold-start latence po nečinnosti, což ve většině produkčních RAG aplikací vede k nasazení vždy-zapnuté kapacity.
pgvector s rozšířením pgvectorscale dosahuje až 28× nižší p95 latence a 16× vyššího QPS než Pinecone s1 indexem při 75 % nižších nákladech (self-hosted EC2).
Hybridní vyhledávání nativně podporují Weaviate (BlockMax WAND + RSF), Milvus 2.5+ (Sparse-BM25), Qdrant v1.9+ a Pinecone se sparse encoderem.
Milvus 2.6 (GA na Zilliz Cloud začátkem 2026) přidává hot/cold tiering pro nákladově efektivní archivaci a posouvá se k plnému retrieval enginu.
Reálné aplikace ukládají 10× až 50× více vektorových dat, než týmy odhadují. Jeden milion dokumentů s embeddings 3072 dim. zabere ~12 GB ještě před indexem.
Co je vektorová databáze a proč ji RAG potřebuje
Vektorová databáze je specializovaný úložný systém optimalizovaný pro ukládání, indexování a vyhledávání vysokorozměrných embedding vektorů, typicky 384 až 3072 dimenzí pro moderní LLM embeddings. Na rozdíl od klasických relačních databází nehledá přesné shody, ale aproximovaně nejbližší sousedy (ANN, approximate nearest neighbors) v metrice kosinové podobnosti, eukleidovské vzdálenosti nebo skalárního součinu.
V kontextu pokročilých RAG pipeline hraje vektorová databáze klíčovou roli retrievalu: pro každý uživatelský dotaz vrací top-k nejrelevantnějších dokumentů, které se následně injektují do kontextu LLM. Bez efektivního ANN indexu (HNSW, IVF, DiskANN, ScaNN) by lineární skenování milionů embeddings trvalo sekundy až minuty namísto desítek milisekund.
V roce 2026 trh dospěl ke konsolidaci kolem osmi produkčních možností ve čtyřech kategoriích: spravované cloudové (Pinecone, Vertex AI Vector Search, Zilliz Cloud), open-source vektorové (Qdrant, Weaviate, Milvus, Chroma, LanceDB), databázová rozšíření (pgvector, Redis Vector, Elasticsearch) a velkoškálové enterprise platformy (Vespa). Hybridní vyhledávání kombinující sparse (BM25) a dense (vector) retrieval se stalo standardem.
Srovnávací tabulka: Qdrant vs Pinecone vs Weaviate vs Milvus vs pgvector
Následující tabulka shrnuje klíčové dimenze rozhodování. Hodnoty latence jsou orientační pro 1M vektorů @ 1536 dimenzí, recall@10 s HNSW indexem.
Vlastnost
Qdrant
Pinecone
Weaviate
Milvus 2.6
pgvector
Typ nasazení
OSS / Cloud
Plně spravovaný
OSS / Cloud
OSS / Zilliz Cloud
PostgreSQL extension
Jazyk implementace
Rust
Proprietární
Go
C++ / Go
C
p50 latence (1M)
~4 ms
~8 ms
~10 ms
~6 ms (GPU)
~25–40 ms
Recall@10 (HNSW)
~98,5 %
~97 %
~97,2 %
~97,9 %
~95–98 %
Hybridní vyhledávání
Ano (v1.9+)
Ano (sparse)
Ano (BlockMax WAND)
Ano (Sparse-BM25)
Částečně (BM25 ext.)
Filtrované vyhledávání
Výborné
Dobré
Dobré
Výborné
Dobré
Cena (managed start)
od $9/měs.
Free tier + usage
od ~$25/měs.
od ~$65/měs.
$0 (self) / Supabase free
Doporučená škála
1M–500M
1M–100M
1M–100M
100M–10B+
do ~10M
Tabulka záměrně vynechává Chromu (vhodnou pro prototypy, nikoli produkci pod vysokou zátěží) a LanceDB (specializace na multimodální data). Pokud potřebujete embeddings konkrétně pro produkční LLM aplikace s nízkými náklady, podívejte se i na techniky jako sémantické cachování LLM odpovědí, které mohou snížit objem vektorových dotazů o desítky procent.
Pinecone: spravovaná služba bez ops režie
Pinecone je nejstarší čistě spravovaná vektorová databáze (od 2019) a v roce 2026 zůstává defaultem pro týmy, které nechtějí provozovat vlastní infrastrukturu. Jeho hlavní devíza je provozní jednoduchost: stačí REST/Python klient, žádný Helm chart, žádné upgrade okno, žádné ladění HNSW parametrů. Pinecone Serverless v3 (2026) přináší automatické škálování compute i storage, ale jeho cold-start latence (200–2000 ms po nečinnosti) ho diskvalifikuje pro low-latency chat aplikace, pokud nezaplatíte za „always-on" kapacitu.
Cenový model Pinecone je nonlineární. Od ~$70/měs. za pod ($0.33/M read units) ceny rychle rostou s objemem dat a query throughputem. Pro RAG systém s 50M vektory a 10 req/s může účet dosáhnout $1500–3000/měs., což je často 3–5× více než ekvivalentní self-hosted Qdrant na EC2 c7g.2xlarge. (V mém posledním projektu jsme přepnuli z Pinecone na Qdrant Cloud a měsíční účet spadl z $2400 na $480.)
Pinecone má proprietární sparse-dense hybridní vyhledávání a nově (od konce 2025) podporu pro reranking přes Cohere Rerank 3 přímo v API. Pokud váš tým nemá platform engineera nebo potřebujete dodat MVP za týden, Pinecone má smysl. Detailní cenovou kalkulačku najdete v oficiální dokumentaci Pinecone pricing.
Qdrant: nejrychlejší open-source databáze pro RAG
Qdrant napsaný v Rustu je v roce 2026 první volbou pro většinu produkčních RAG nasazení střední škály (1M až 500M vektorů). Důvody: nejnižší p50 latence v open-source kategorii (~4 ms), excelentní filtrované vyhledávání díky payload indexům (až 10× rychlejší než Pinecone na filtru typu category=X AND price<100), a podpora int8 / binary kvantizace, která snižuje paměťovou stopu o 4–32×.
Qdrant Cloud začíná na $9/měs. (cluster 1 GB), ale skutečnou hodnotu rozbalíte při self-hostingu: jeden node c7g.2xlarge (~$120/měs. on-demand, ~$70/měs. reserved) zvládne 50M vektorů s p95 pod 20 ms. Distribuovaný režim s shardingem podporuje horizontální škálování až do miliard záznamů. Qdrant v1.9+ podporuje named vectors (multi-vector per point) pro hybridní dense+sparse retrieval, což je klíčové pro moderní RAG s ColBERT-style late interaction modely.
Praktická úskalí: Qdrant nemá vestavěný embedding generator (na rozdíl od Weaviate). Musíte si tedy postavit vlastní pipeline pro OpenAI text-embedding-3 nebo lokální model. Také vyžaduje pečlivé ladění HNSW parametrů (m, ef_construct, ef) pro váš dataset; defaulty fungují, ale ne optimálně. Doporučujeme začít s m=16, ef_construct=128 a postupně tunit podle recall vs QPS křivky.
Weaviate: král hybridního vyhledávání
Weaviate napsaný v Go vyhrává v jednom konkrétním scénáři: hybridní vyhledávání nejvyšší kvality. Implementace BlockMax WAND (state-of-the-art sparse algoritmus) kombinovaná s Relative Score Fusion (RSF) místo primitivního RRF dává v reálných právních, medicínských a e-commerce datasetech o 8–15 % vyšší NDCG@10 než kombinace Qdrant + samostatný BM25 servis.
Druhý unikátní rys: vestavěné embedding moduly. Místo manuální vektorizace stačí poslat raw text. Weaviate ho přes nakonfigurovaný modul (text2vec-openai, text2vec-cohere, text2vec-transformers) přeloží na vektory a indexuje. To dramaticky zjednodušuje pipeline, ale za cenu vendor lock-inu na konkrétní embedding provider. V kombinaci se strukturovanými výstupy z LLM dostanete velmi čistou end-to-end RAG architekturu.
Slabiny: vyšší paměťová náročnost než Qdrant (~30 % více RAM na stejný dataset kvůli inverted indexům), pomalejší absolutní ANN latence (~10 ms p50 vs 4 ms u Qdrantu), a komplexnější config (Schemas, Modules, Vectorizers). Weaviate Cloud Services začínají kolem $25/měs., ale produkční clustery typicky stojí $200–500/měs. Pokud „hybridní kvalita je vaše top priorita", Weaviate je správná volba.
Milvus: vektorová databáze pro miliardy záznamů
Milvus 2.6 (GA na Zilliz Cloud začátkem 2026) je průmyslový retrieval engine postavený na disagregované architektuře compute/storage. Zatímco Qdrant nebo Weaviate komfortně zvládají desítky milionů vektorů, Milvus se rutinně provozuje na stovkách milionů až miliardách záznamů. Mluvíme o vyhledávacích firmách, e-commerce platformách a genomickém výzkumu.
Klíčové novinky 2.6: hot/cold tiering pro nákladově efektivní archivaci starších dat (často 70 % nákladů ušetří přesunem do S3-tier storage), GPU acceleration přes CUDA-native indexy (až 10× rychlejší build a 3× nižší dotazovací latence), a Sparse-BM25 nativní hybridní search. Milvus podporuje 11 typů indexu (HNSW, IVF_FLAT, IVF_PQ, DiskANN, ScaNN, GPU_IVF, …), což dává jemnou kontrolu nad kompromisem rychlost/přesnost/paměť.
Provozní složitost je jeho hlavní nevýhoda. Milvus cluster se skládá z osmi mikroservisů (Proxy, RootCoord, DataCoord, QueryCoord, IndexCoord, DataNode, QueryNode, IndexNode) plus Pulsar/Kafka, etcd a MinIO. Kubernetes nasazení s Helm chartem je proveditelné, ale vyžaduje dedikovaný platform team. Pokud nejste na miliardní škále, Milvus je pravděpodobně přeprojektovaný. Detaily v oficiálních release notes Milvus 2.6.
pgvector: vektory přímo v PostgreSQL
V roce 2026 prošel pgvector revolucí. Verze 0.9 (vydaná v dubnu 2026) přidává HNSW index s iterative search pro filtrované dotazy, paralelní build indexu, a integraci s pgvectorscale od Tiger Data (dříve Timescale), která zavádí DiskANN-inspirovaný StreamingDiskANN index. Výsledek? Při 99% recall dosahuje pgvector + pgvectorscale 28× nižší p95 latence a 16× vyššího QPS než Pinecone s1 index, a to za 75 % nižší cenu, pokud běžíte na vlastní EC2.
Praktická hodnota pgvectoru je v transakční konzistenci: vaše dokumenty, metadata a embeddings žijí v jedné databázi, jeden ACID transakční scope, jeden backup, jeden tým, který to provozuje. Pro RAG systémy s méně než 10M vektory je pgvector v 90 % případů nejlepší volba. Bonus: SQL JOIN s aplikační tabulkou je triviální (např. SELECT * FROM docs JOIN embeddings USING (id) ORDER BY embedding <=> $1 LIMIT 10).
Limity: čistý pgvector bez pgvectorscale začíná zaostávat nad ~10M vektorů. Hybridní vyhledávání není nativní, takže musíte kombinovat tsvector (PostgreSQL FTS) s vektorovým indexem manuálně. A pokud váš PostgreSQL už trpí pod zátěží OLTP, přidání heavy ANN dotazů ho položí. Doporučujeme dedikovaný read replica pro vektorové dotazy. Aktuální verze najdete na oficiálním GitHub repo pgvector.
Latence, QPS a recall: co skutečně benchmarky 2026 ukazují
Benchmarky vektorových databází jsou notoricky zavádějící. ANN-Benchmarks používají low-dimensional datasety jako SIFT (128 dim.) a GIST (960 dim.), ale moderní LLM embeddings mají 1536 (text-embedding-3-small) až 3072 dimenzí (text-embedding-3-large). Leaderboardy odměňují statické podmínky, ale produkce vyžaduje souběžné writes, metadata filtry a špičky concurrency.
Reálná čísla z nezávislého benchmarku vector-db-benchmark na 10M vektorů @ 1536 dim, k=10, 95% recall, c7g.2xlarge:
Klíčový poznatek: p99 latence rozhoduje user experience více než p50. Pinecone Serverless má skvělou p50, ale p99 zničí každého, kdo cílí na chat UI pod 1s end-to-end. Qdrant a Milvus drží tail latency výrazně nižší díky in-memory architektuře.
Druhý poznatek: filtrovaný recall ≠ unfiltrovaný recall. Mnoho databází dosahuje 98 % recall na čistém ANN dotazu, ale s filtrem WHERE category=X spadne na 70–85 %, protože ANN graf prochází přes vyfiltrované uzly. Qdrant a Milvus mají pre-filtering, který tento problém minimalizuje; Pinecone a starší pgvector trpí post-filteringem nejvíce.
Jak vybrat vektorovou databázi pro váš RAG projekt
Místo abstraktního „která je nejlepší" odpovězte na čtyři konkrétní otázky:
Jaká je velikost vašeho datasetu za 12 měsíců? Týmy typicky podcení velikost 10–50×. Pokud cílíte na 1M vektorů dnes, plánujte na 50M příští rok.
Máte platform engineera? Pokud ne, jděte na Pinecone nebo Zilliz Cloud (managed Milvus). Pokud ano, zvažte Qdrant, Weaviate, nebo pgvector.
Jaký je váš stack? Postgres-heavy znamená pgvector. GCP-native znamená Vertex AI Vector Search. Multi-cloud volí Qdrant. Hybrid-search-kritické volí Weaviate. Miliardy záznamů znamenají Milvus nebo Vespa.
Jaký je váš latency budget? Pod 50 ms end-to-end RAG vyžaduje Qdrant nebo Milvus s GPU. Tolerance 200+ ms? Cokoli funguje.
Praktický postup: prototypujte s Chroma nebo pgvector (nulová setup režie), pak migrujte na produkční volbu po prvním load testu. Migrace mezi vektorovými databázemi je relativně přímočará, protože embeddings jsou portable formát (numpy / parquet). Vyhněte se předčasné optimalizaci na „nejlepší" databázi, dokud nemáte reálný traffic pattern. (Tuhle radu jsem se naučil těžce: minulé léto jsem strávil dva týdny laděním Milvusu pro projekt, který nakonec sotva přerostl 200k vektorů.)
Implementační příklad: Qdrant + Python pro RAG
Následující kompletní příklad nastaví Qdrant kolekci, vloží dokumenty s OpenAI embeddings a provede sémantické vyhledávání s metadata filtrem. Předpokládá běžící Qdrant instanci (docker run -p 6333:6333 qdrant/qdrant:v1.10).
from qdrant_client import QdrantClient
from qdrant_client.models import (
Distance, VectorParams, PointStruct,
Filter, FieldCondition, MatchValue,
)
from openai import OpenAI
import uuid
oai = OpenAI()
qdrant = QdrantClient(url="http://localhost:6333")
COLLECTION = "kb_docs"
DIM = 1536 # text-embedding-3-small
# 1) Vytvoreni kolekce s HNSW indexem a int8 kvantizaci pro 4x usporu RAM
qdrant.recreate_collection(
collection_name=COLLECTION,
vectors_config=VectorParams(size=DIM, distance=Distance.COSINE),
hnsw_config={"m": 16, "ef_construct": 128},
quantization_config={
"scalar": {"type": "int8", "quantile": 0.99, "always_ram": True}
},
)
def embed(text: str) -> list[float]:
resp = oai.embeddings.create(model="text-embedding-3-small", input=text)
return resp.data[0].embedding
# 2) Bulk insert s payload metadaty (kategorie, datum, autor)
documents = [
{"text": "RAG kombinuje retrieval a generovani...",
"category": "ai", "year": 2026, "lang": "cs"},
{"text": "Vektorove databaze indexuji embeddings...",
"category": "infra", "year": 2026, "lang": "cs"},
]
points = [
PointStruct(
id=str(uuid.uuid4()),
vector=embed(doc["text"]),
payload=doc,
)
for doc in documents
]
qdrant.upsert(collection_name=COLLECTION, points=points)
# 3) Semanticke vyhledavani s pre-filtrem na metadata
query = "Jak funguje retrieval v RAG?"
results = qdrant.search(
collection_name=COLLECTION,
query_vector=embed(query),
query_filter=Filter(
must=[
FieldCondition(key="lang", match=MatchValue(value="cs")),
FieldCondition(key="year", match=MatchValue(value=2026)),
]
),
limit=5,
search_params={"hnsw_ef": 128, "exact": False},
)
for hit in results:
print(f"score={hit.score:.3f} cat={hit.payload['category']}")
print(hit.payload["text"][:200])
Tři klíčové detaily v ukázce: (1) int8 scalar kvantizace sníží paměť 4× s minimální ztrátou recall; (2) pre-filtering přes query_filter garantuje, že HNSW prochází jen relevantní uzly (rychlejší a přesnější než post-filter); (3) hnsw_ef v search parametrech tunuje recall/latence kompromis runtime, takže nemusíte rebuildit index.
Často kladené otázky
Která vektorová databáze je nejlepší pro RAG v roce 2026?
Pro střední škálu (1M–500M vektorů) je nejlepší volba Qdrant díky kombinaci nejnižší p50 latence (~4 ms), výborného filtrovaného vyhledávání a rozumné ceně. Pro týmy bez DevOps zdrojů Pinecone, pro hybridní vyhledávání Weaviate, pro miliardy záznamů Milvus a pro projekty pod 10M vektorů s existujícím PostgreSQL je pgvector + pgvectorscale nejrychlejší cesta k produkci.
Kolik stojí Pinecone vs Qdrant?
Pinecone začíná zdarma (free tier), placené pody od ~$70/měs., ale účet rychle roste s objemem. Konkrétně 50M vektorů a 10 req/s typicky stojí $1500–3000/měs. Qdrant Cloud začíná na $9/měs. (1 GB cluster), self-hosted na c7g.2xlarge stojí ~$70–120/měs. a zvládne stejných 50M vektorů. Pro produkční RAG je Qdrant typicky 3–5× levnější než Pinecone na ekvivalentní zátěž.
Co je hybridní vyhledávání ve vektorové databázi?
Hybridní vyhledávání kombinuje sparse retrieval (BM25, SPLADE) s dense vector retrieval a fúzuje skóre přes RRF, RSF nebo learned reranker. Výsledkem je vyšší recall a přesnost u dotazů s konkrétními klíčovými slovy (jména, kódy, číslice), kde čistý sémantický search selhává. V 2026 ho nativně podporují Weaviate (BlockMax WAND + RSF), Milvus 2.5+ (Sparse-BM25), Qdrant v1.9+ (named vectors) a Pinecone (proprietární sparse).
Mohu použít pgvector místo dedikované vektorové databáze?
Ano. Pro datasety pod 10M vektorů je pgvector v 90 % případů nejlepší volba. S rozšířením pgvectorscale dosahuje 28× nižší p95 latence než Pinecone s1 při 99% recall a 75 % nižších nákladech. Nad 10M vektorů nebo s vysokou concurrency začíná zaostávat za Qdrantem či Milvusem, a hybridní vyhledávání musíte řešit manuální kombinací tsvector a vektorového indexu.
Jaký je rozdíl mezi HNSW a IVF indexem?
HNSW (Hierarchical Navigable Small World) je grafový index s výbornou kvalitou recall/latence kompromisu, ale vyšší paměťovou stopou (graf v RAM). IVF (Inverted File Index) klastruje vektory do „buněk" a hledá v top-n nejbližších klastrech. Má menší paměť, ale horší recall. V 2026 většina produkčních RAG nasazení používá HNSW; IVF má smysl jen u extrémně velkých datasetů (miliardy vektorů), kde paměť HNSW není únosná. Modernější DiskANN kombinuje výhody obojího.
Article changelog (1)
— SEO meta refreshed (title and description updated)
Praktický průvodce produkční sémantickou cache pro LLM v Pythonu. Dvouvrstvá architektura s Redis a embeddings, ladění similarity threshold, monitoring false positive rate a reálné case studies s úsporou 40-70 %.
Jazykové modely nemají paměť — každý dotaz zpracovávají od nuly. Naučte se přidat perzistentní paměť do AI agentů v Pythonu pomocí frameworků Mem0, Letta a LangMem. Praktické příklady kódu a srovnání pro produkci.
