Vektorové databáze pro AI: Qdrant, Chroma a pgvector v praxi
Když RAG chatbot odpoví špatně, většina týmů začne ladit jazykový model. Mění prompt, zkouší dražší model, přidává instrukce. Jenže chyba je skoro vždy o krok dřív — ve vyhledávání. Pokud databáze vrátí pět nesouvisejících odstavců, i ten nejchytřejší model z nich sestaví jen sebejistě znějící nesmysl.
Vektorová databáze je vrstva, která rozhoduje o tom, jestli se modelu dostane správný kontext. Ovlivňuje latenci odpovědi, náklady na provoz i to, jestli systém přežije růst z tisíce dokumentů na deset milionů. A přestože trh nabízí desítky řešení, pro drtivou většinu českých projektů se rozhodnutí smrskne na tři jména: Qdrant, Chroma a pgvector.
Tento návod je porovná na tom, na čem opravdu záleží — výkon, škálování, cena provozu a náročnost nasazení. Na konci najdete rozhodovací strom, kdy sáhnout po kterém. Žádný marketing, konkrétní čísla.
Proč o kvalitě RAG rozhoduje databáze, ne model
Připomeňme, jak RAG (Retrieval-Augmented Generation) funguje. Dokumenty se rozsekají na kousky, každý kousek se převede na vektor — seznam několika set až několika tisíc čísel, který zachycuje význam textu. Když přijde dotaz, převede se na vektor stejným způsobem a databáze hledá kousky, jejichž vektory jsou mu nejblíž. Těch pár nejbližších pak dostane model jako podklad pro odpověď.
Celý trik stojí na jedné operaci: rychle najít nejpodobnější vektory mezi miliony ostatních. Přesné hledání by bylo příliš pomalé, takže databáze používají přibližné hledání nejbližších sousedů (ANN), nejčastěji přes index typu HNSW. Ten obětuje trochu přesnosti za obrovské zrychlení. A právě tady se jednotlivá řešení liší nejvíc — v tom, jak dobře zvládají velký objem, filtrování podle metadat a nízkou latenci pod zátěží.
💡 Klíčový princip
Kvalita odpovědi nikdy nepřekročí kvalitu vyhledávání. Pokud retrieval vrátí špatné kousky, model nemá z čeho stavět a začne halucinovat. Ladit vektorovou databázi má proto skoro vždy větší dopad než měnit model.
Embeddingy: kde RAG doopravdy začíná
Než začnete řešit databázi, potřebujete embeddingový model — ten převádí text na vektory. Jeho volba určuje dvě věci: jak přesné bude vyhledávání a kolik místa data zaberou. Rozměr vektoru (počet čísel) totiž přímo diktuje spotřebu paměti. Vektor o 1 024 rozměrech ve formátu float32 zabere 4 kB. Při 10 milionech dokumentů je to 40 GB jen za vektory, ještě před indexem.
| Model | Rozměry | Cena / 1M tokenů | Kdy sáhnout |
|---|---|---|---|
| OpenAI text-embedding-3-small | 1 536 | $0,02 | Bezpečná výchozí volba pro 90 % projektů |
| OpenAI text-embedding-3-large | 3 072 | $0,13 | Vyšší přesnost, když na retrievalu záleží |
| Voyage voyage-3-large | 1 024–2 048 | ~$0,18 | Nejvyšší kvalita retrievalu v produkci |
| BGE-M3 | 1 024 | zdarma (vlastní HW) | Self-hosting, data nesmí opustit firmu |
Podle dostupných benchmarků z roku 2026 vede v kvalitě retrievalu Voyage voyage-3-large, které překonává OpenAI large zhruba o 10 %. Pro kód existuje specializované voyage-code-3. Pokud ale nechcete řešit rozpočet ani citlivost dat, OpenAI 3-small je pořád rozumný výchozí bod. Kdo potřebuje mít data doma, sáhne po open-source BGE-M3, které lze provozovat lokálně na vlastním hardwaru.
⚡ Tip: Matryoshka embeddingy
Modely OpenAI 3 podporují zkrácení vektoru — místo plných 3 072 rozměrů si můžete vyžádat 512 nebo 1 024 a vektor stále funguje slušně. Ušetříte tím paměť i náklady na úložiště, aniž byste museli přepínat model. Vždy ale změřte, o kolik klesla přesnost na vašich datech.
Náklady na embedding jsou obvykle jednorázové (indexace) plus malá průběžná platba za dotazy. U velkých znalostních bází se ale sčítají — detailní kalkulaci najdete v průvodci náklady na AI API a tokeny.
Qdrant, Chroma a pgvector: velké srovnání
Tady je jádro věci. Tři databáze, tři odlišné filozofie. Qdrant je postavený na rychlost, Chroma na jednoduchost, pgvector na to, že už máte PostgreSQL. Srovnání na parametrech, které v produkci rozhodují:
| Parametr | Qdrant | Chroma | pgvector |
|---|---|---|---|
| Architektura | Samostatná DB v Rustu | Embedded (jako SQLite) | Rozšíření PostgreSQL |
| Nasazení | Docker / cluster / cloud | V procesu appky, 1 server | Uvnitř stávající databáze |
| Kvantizace | Skalární, product, binární (až 32×) | Nativně nemá (2026) | Halfvec / bit, ručně |
| Filtrování metadat | Payload index v grafu HNSW | Základní, na metadatech | SQL WHERE + iterative scan |
| Škálování / sharding | Distribuovaný mód (Raft) | Jen vertikální | Bez nativního shardingu |
| Latence @ 10 mil. | ~4 ms medián, ~12 ms p99 | Klesá s objemem | ~45 ms (bez tuningu) |
| Ideální scénář | Nová appka, rychlost, velký objem | Prototyp, MVP, malá data | Už běžíte na Postgresu |
Qdrant — když jde o rychlost a růst
Napsaný v Rustu, s nejnižší latencí z trojice a vestavěnou kvantizací, která zmenší paměťovou stopu 4× až 32×. Payload indexy má integrované přímo do grafu HNSW, takže filtrované hledání zůstává rychlé. Nasadíte ho jako jeden binární soubor a v případě potřeby rozšíříte na cluster s Raft konsenzem.
Chroma — když chcete výsledek dnes
Běží embedded, podobně jako SQLite — žádný server, žádná infrastruktura. Ideální pro prototyp, MVP nebo interní nástroj do pár set tisíc vektorů. Produkční příběh se v letech 2025–2026 hodně zlepšil a přibyl Chroma Cloud, ale bez nativní kvantizace se u stovek milionů vektorů stává provoz drahým.
pgvector — když už máte PostgreSQL
Rozšíření, které přidá vektorové hledání do databáze, kterou už provozujete. Žádný nový systém, jedno zálohování, jedna transakční logika. Verze 0.8 přinesla iterative scan, který výrazně zlepšil filtrované dotazy. Do zhruba 10 milionů vektorů odvede skvělou práci s minimem provozní režie.
Výkon a škálování: kde která databáze narazí
Čísla z veřejných benchmarků jsou celkem konzistentní. Qdrant dává nejnižší latenci — medián kolem 4 ms a p99 kolem 12 ms na deseti milionech vektorů. Pro dedikovaný retrieval pod zátěží je to referenční hodnota, kterou ostatní dohánějí.
pgvector má jasný strop. Jeho index HNSW drží výkon, dokud se jeho aktivní část vejde do RAM. Jakmile pracovní sada přeteče paměť, latence kvůli náhodnému přístupu prudce roste. Na srovnatelném hardwaru zvládne dotaz nad 10milionovým indexem za zhruba 45 ms, zatímco Qdrant za 8 ms. Rozšíření pgvectorscale od Timescale tenhle odstup na některých benchmarcích výrazně stahuje, ale je to další komponenta, kterou musíte provozovat.
Chroma se nesrovnává na stejném poli — je stavěná na jeden proces nebo jeden server. Do několika set tisíc vektorů je svižná a bezúdržbová. Za tou hranicí ale naráží na chybějící sharding i kvantizaci a začíná se z ní stávat úzké hrdlo.
„Pokud máte existující Postgres app a jste pod 50 miliony vektorů, použijte pgvector. Když stavíte novou aplikaci a záleží na rychlosti, jděte do Qdrantu."
— Syntéza veřejných benchmarků vektorových databází, 2026
Pozor na jeden častý omyl: benchmarky se dělají na milionech vektorů, ale realita českého projektu je často 50 000 dokumentů. V tom měřítku jsou všechny tři databáze rychlé a rozdíl v latenci nikdo nepocítí. Optimalizovat na 10 milionů, když jich máte 50 tisíc, znamená platit provozní daň za výkon, který nevyužijete.
Kdy zvolit co: rozhodovací strom
Zapomeňte na tabulky benchmarků a odpovězte si na tři otázky: kolik vektorů budete mít, jestli už provozujete Postgres a jestli citlivá data smějí opustit firmu. Z toho vypadne odpověď skoro sama.
✅ Který systém vybrat
- Prototyp, MVP nebo interní nástroj do ~500 tisíc vektorů → Chroma (embedded, nasadíte za odpoledne)
- Už běžíte na PostgreSQL a máte pod 10 milionů vektorů → pgvector (žádný nový systém navíc)
- Nová aplikace, kde je vyhledávání jádrem produktu, a čekáte růst → Qdrant (rychlost a distribuovaný mód)
- Přes 10 milionů vektorů a potřebujete p95 pod 50 ms → Qdrant (nebo pgvector + pgvectorscale)
- Citlivá data, která nesmějí ven → Qdrant nebo pgvector self-hosted + lokální embeddingy
🎯 Klíčový poznatek
Nezačínejte volbou „nejlepší" databáze. Začněte tím, kolik dat opravdu máte a co už provozujete. Naprostá většina projektů rozjede pilot na Chromě nebo pgvectoru a k Qdrantu přejde, teprve až objem a latence dají jasný důvod. Předčasná optimalizace vektorové databáze je klasická past.
Sedm tipů pro produkční RAG
Volba databáze je jen půlka práce. Ať už stavíte firemní znalostní bázi, nebo ji integrujete přes vlastní API, o kvalitě retrievalu rozhoduje těchto sedm věcí:
1. Chunky kolem 512 tokenů. Empiricky ověřené optimum. Menší kousky ztrácejí kontext, větší rozmělňují relevanci. U strukturovaných dokumentů kombinujte fixní délku s dělením podle nadpisů.
2. Hybridní vyhledávání. Spojte vektorové (význam) s klíčovým (přesnost). Na dotaz „cena produktu ABC-42" najde vektorové hledání podobné otázky, ale klíčové zajistí přesně ten produkt. Pro rok 2026 je to standard.
3. Filtrujte podle metadat. Ke každému kousku ukládejte jazyk, datum, zdroj, oddělení. Dotaz pak zúžíte ještě před samotným hledáním — rychleji a přesněji.
{
"vector": [0.12, -0.44, 0.09, ...],
"filter": {
"must": [
{ "key": "jazyk", "match": { "value": "cs" } },
{ "key": "rok", "range": { "gte": 2025 } }
]
},
"limit": 5
}
4. Zapněte kvantizaci u velkých bází. Skalární nebo binární kvantizace v Qdrantu zmenší paměť 4× až 32× s malou ztrátou přesnosti. Rozhoduje o tom, jestli se index vejde do RAM, nebo ne — a to je u latence zásadní.
5. Hlídejte správnou metriku podobnosti. Cosine, dot product a euklidovská vzdálenost nejsou zaměnitelné. Musí sedět s tím, na co byl embeddingový model trénovaný, jinak dostáváte tiše horší výsledky.
6. Měřte recall, ne jen latenci. Rychlá databáze, která vrací špatné kousky, je k ničemu. Držte si testovací sadu dotazů se známými správnými odpověďmi a sledujte, kolik jich retrieval trefí.
7. Plánujte reindexaci. Když změníte embeddingový model, musíte přepočítat všechny vektory — staré a nové se nedají míchat. Počítejte s tím dřív, než vás to překvapí v produkci.
⚠️ Nejčastější chyba
Týmy nasadí databázi s prázdnými metadaty a spoléhají čistě na sémantickou podobnost. Jakmile báze naroste, retrieval začne míchat dokumenty z různých období, oddělení a jazyků dohromady. Metadata a filtrování nejsou nadstavba — jsou to základní stavební kámen kvalitního RAG.
Shrnutí: rozhodněte podle měřítka, ne podle hype
Qdrant, Chroma a pgvector nejsou konkurenti, kteří by řešili totéž. Chroma vás rychle dostane od nuly k funkčnímu prototypu. pgvector přidá vektorové hledání do databáze, kterou už máte, bez další infrastruktury. Qdrant je volba, když je vyhledávání jádrem produktu a čekáte růst do milionů vektorů.
Pro naprostou většinu českých firem je nejlepší postup jednoduchý: postavte pilot na tom nejjednodušším, co pokryje aktuální objem, změřte recall i latenci na reálných dotazech a k výkonnějšímu řešení přejděte, teprve až vás k tomu dotlačí data. Zbytek úspěchu RAG leží v embeddingu, chunkování a metadatech — o databázi nakonec rozhoduje jen jedno číslo: kolik vektorů skutečně máte.
📌 Hlavní závěr
Nejdřív změřte měřítko, pak vybírejte databázi. Do 500 tisíc vektorů Chroma, do 10 milionů na Postgresu pgvector, nad to nebo když je rychlost jádro produktu Qdrant. A pamatujte: kvalitu RAG táhne retrieval, ne model — proto se vyplatí investovat čas do embeddingu, chunků a filtrování víc než do výběru „nejlepší" databáze.
Zdroje a reference
- Layerbase — „Vector databases compared 2026: pgvector vs Qdrant vs Chroma"
- AWS Database Blog — „Supercharging vector search performance with pgvector 0.8.0 on Amazon Aurora PostgreSQL" (2026)
- PostgreSQL.org — „pgvector 0.8.0 Released" (iterative scan pro filtrované dotazy)
- ClickHouse — „How to scale vector search in Postgres (pgvector) for RAG" (paměťové limity HNSW)
- Qdrant — dokumentace ke kvantizaci (skalární / product / binární) a distribuovanému módu
- Timescale — pgvectorscale benchmark (QPS při 99% recall na 50M vektorů)
- PE Collective — „Best Embedding Models 2026" (OpenAI, Voyage, BGE-M3; rozměry a ceny)
- Firecrawl — „Best Vector Databases in 2026: A Complete Comparison Guide"