Keď sa firma rozhodne nasadiť RAG (Retrieval-Augmented Generation) nad firemnou dokumentáciou, prvá technická otázka znie: kde uložíme vektory? Odpoveď nie je neutrálna — výber ovplyvní latentnosť odpovedí, mesačné náklady na infraštruktúru, náročnosť údržby a to, čo bude možné a čo nie, keď sa objem dát zdvojnásobí. V praxi vidíme, že tímy najčastejšie siahajú po jednom z týchto štyroch riešení: pgvector, Qdrant, Weaviate a Milvus. Každé má iný záber, iné silné stránky a iný kontext, v ktorom dáva zmysel.
Tento článok nie je benchmarkový súboj (dostupné verejné benchmarky sú z podstaty závislé od HW, dimenzionality a záťažového vzoru). Je to rozhodovací rámec — ako si vybrať na základe toho, čo vaša firma skutočne potrebuje.
Čo majú všetky štyri spoločné
Všetky štyri riešenia zvládajú approximate nearest neighbor (ANN) vyhľadávanie s HNSW indexom, filtrovaním podľa metadát a integráciou so štandardnými embedding modelmi. Všetky sú open-source (Apache 2.0 alebo ekvivalent) s možnosťou self-host alebo managed cloud variantu. Bežný embedding rozmer 1 024 alebo 1 536 nepredstavuje problém pre žiadne z nich.
Rozdiel začína, keď narazíte na škálu, požiadavky na konzistenciu, existujúcu infraštruktúru alebo potrebu hybridného vyhľadávania (vektor + keyword). Tam sa štyri cesty rozvetvujú.
pgvector — keď už máte Postgres
pgvector je rozšírenie PostgreSQL. Neexistuje ako samostatná databáza — beží vnútri vašej existujúcej PG inštancie. Toto je zároveň jeho najsilnejší argument aj jeho hlavné obmedzenie.
Kedy to dáva zmysel:
Ak vaša firma prevádzkuje PostgreSQL a objem vektorov nepresahuje rádovo desiatky miliónov, pgvector je legitímna produkčná voľba. Výhoda je zásadná: vektory, štruktúrované dáta a metadata žijú v jednej databáze, pod jednou transakciou, s jedným zálohovacím procesom. Nie je potrebná synchronizácia medzi dvoma systémami, nie je potrebná ďalšia infra.
Verzia pgvector z začiatku roku 2026 pridala podporu sparse vektorov a výrazne zlepšila výkon IVFFlat indexu. S HNSW indexom a primeranou konfiguráciou zvládne databáza na bežnom serveri 5 000 až 15 000 QPS pri zbierke okolo 10 miliónov vektorov s dimenziou 1 024. To je pre veľkú väčšinu B2B RAG nasadení nad internou dokumentáciou dostatočné.
Kde má limity:
Pri zbierke nad 50 miliónov vektorov začína PG narážať na vlastnosti architektúry — rowstore optimalizovaný pre transakčné záťaže, nie pre pure-ANN throughput. Výkon klesá a škálovanie si vyžaduje buď sharding alebo prechod na iné riešenie. Ďalší limit: pgvector nemá natívny hybridný search — kombinovanie vektorového a keyword vyhľadávania vyžaduje manuálne zostavenie pipeline, napríklad cez tsvector a ručný RRF (Reciprocal Rank Fusion).
Typický profil projektu: interná knowledge base alebo zákaznícka podpora, zbierka 1–5 miliónov vektorov, tím, ktorý spravuje existujúci Postgres, a preference pred rozširovaním infraštruktúry.
Qdrant — výkon a single-node self-host
Qdrant je databáza postavená od nuly pre vektorové vyhľadávanie. Napísaná v Ruste, s dôrazom na výkon a jednoduché self-host nasadenie — binárka alebo Docker kontajner, žiadne external závislosti.
Kľúčová vlastnosť, ktorá Qdrant odlišuje v roku 2026: natívna podpora ColBERT-style multi-vector (late interaction), teda možnosť uložiť niekoľko vektorov pre jeden dokument a vyhľadávať cez ich interakciu. To umožňuje state-of-the-art retrieval bez externého reranker servera — Qdrant zariadi late interaction priamo v indexe. Pre projekty, kde záleží na presnosti a nechcete stavať separátny reranker service, je to výrazná výhoda.
Výkonnostná charakteristika: pri 10 miliónoch vektorov, 1 024 dimenziách, záťaži okolo 1 000 QPS sa pohybujeme na P99 latencii okolo 12 ms. Škáluje dobre do stoviek miliónov vektorov na single-node pri dostatočnej RAM, prípadne cez Qdrant Cloud managed service pre väčšie inštalácie.
Hybridný search: Qdrant podporuje sparse vektory (BM25-style) ako prvotriednú funkciu — teda dense vektor + sparse vektor sa vyhľadáva v jednom prechode, bez ručného mixovania výsledkov. Pre typický enterprise RAG scenár (technická dokumentácia, produktové katalógy, servisné príručky) je to ideálne — presné kľúčové slová (čísla dielov, kódy, špecifické termíny) zachytí sparse vetva, sémantiku zachytí dense vetva.
Kedy to dáva zmysel:
Tím chce self-host riešenie, predvídateľnú latenciu, natívny hybrid search a nechce spravovať distribuovaný cluster. Zbierka môže byť od miliónov do stoviek miliónov vektorov. Operátori s jednou osobou na infra preferujú jednoduché nasadenie.
Kde má limity:
Pri naozaj veľkých zbierkach (miliardy vektorov) je natívna distribúcia obmedzená oproti Milvusu. Ekosystém integračných konektorov je menší než u Weaviate.
Weaviate — modulárny hybrid search
Weaviate má inú filozofiu než Qdrant: každá schopnosť je modul — embedding generácia, keyword indexovanie, reranking, multimodálny input. To uberá na jednoduchosti, ale dáva veľkú flexibilitu bez custom kódu.
Kľúčová vlastnosť: natívny hybrid search (BM25 + dense vector + metadata filter) ako prvotrieda v query API. BM25 index a vector index sú integrované do jedného query plánera s automatickým RRF fusion. Weaviate tiež vyniká bohatým GraphQL query API, čo oceňujú tímy, ktoré potrebujú komplexné filtrovanie (multi-tenant, prístupové práva, hierarchické metadáta).
Výkon: orientačne 25 000 až 50 000 QPS pri 10 miliónoch vektorov, P99 latencia okolo 16 ms. Náklady na cloud variantu (Weaviate Cloud) sú vyššie než Qdrant, no tím získa managed reranking, monitoring a SLA.
Kedy to dáva zmysel:
Multi-tenant nasadenie (viac zákazníkov/oddelení v jednej inštancii s izolovanými dátami), potreba pokročilého filtrovania, tím, ktorý ocení managed service s bohatším ekosystémom. Dobrá voľba aj pre projekty s multimodálnym obsahom, kde Weaviate modul pre image embedding ušetrí custom kód.
Kde má limity:
Modulárna architektúra pridáva operačnú komplexitu — viac konfigurácií, viac možností zlyhania. Pre jednoduchý RAG use-case je Weaviate over-engineered. Schema-first prístup (definovanie typov pred indexovaním) môže spomaľovať prototypovanie.
Milvus — extrémna škála
Milvus je distributed-first od prvého riadku kódu. Beží na Kubernetes, s etcd pre koordináciu, S3-compatible úložiskom pre persistenciu a separátnymi komponentami pre ingestion, indexovanie a query. Táto architektúra je overhead pre malé projekty — a výhoda pre veľké.
Pri zbierkach v miliardách vektorov Milvus dosahuje priepustnosť 100 000+ QPS s horizontálnym škálovaním. GPU-akcelerované ANN vyhľadávanie ďalej znižuje latenciu pri veľkých indexoch. Managed verzia — Zilliz Cloud — preberá operačnú záťaž.
Kedy to dáva zmysel:
Zbierka nad 100 miliónov vektorov, high-throughput záťaž (e-commerce personalizácia, odporúčacie systémy, vektorové vyhľadávanie v miliardovom katalógu), tím s DevOps kapacitou na prevádzku Kubernetes stacku.
Kde má limity:
Pre bežný enterprise RAG s miliónmi vektorov je Milvus zbytočný overhead. Minimálna produkčná inštalácia vyžaduje niekoľko komponentov — etcd cluster, MinIO/S3, query nodes, data nodes. Pre jednočlenný tím je to príliš veľa infra na udržanie. Hybridný search existuje, ale je menej plynulý než u Qdrant alebo Weaviate.
Rozhodovací rámec: tri otázky pred výberom
Namiesto porovnávania v tabuľke (kde každé pole vyžaduje kontext) odporúčame zodpovedať tri otázky v poradí:
1. Aká je veľkosť zbierky teraz a za 2 roky?
- Do 5 miliónov vektorov a existujúci Postgres → skúste
pgvectornajprv. Vyhnete sa novej infra. - 5 miliónov až stovky miliónov →
QdrantaleboWeaviatepodľa nasledujúcich kritérií. - Miliardy vektorov alebo 100 000+ QPS →
Milvus/ Zilliz Cloud.
2. Koľko ľudí spravuje infraštruktúru?
- Jeden vývojár alebo malý tím →
Qdrant(jednoduchý self-host, binárka/Docker, minimálne závislosti). - Tím s DevOps kapacitou, ktorý preferuje managed service →
Weaviate CloudaleboZilliz Cloud. - Kubernetes-natívny tím s skúsenosťami s distributed systémami →
Milvus.
3. Aká je štruktúra dotazov?
- Pure sémantické vyhľadávanie → akákoľvek z týchto DB.
- Hybrid (keyword presnosť + sémantika) →
Qdrant(sparse + dense natívne) aleboWeaviate(BM25 + dense natívne). Ak použijetepgvector, hybrid treba dovariť manuálne. - Multi-tenant s izolovanými dátami, komplexné filtrovanie →
Weaviatemá najvyspelejšie query plánovanie. - ColBERT / multi-vector late interaction →
Qdrantv roku 2026 ako jediný z týchto štyroch natívne.
Výkonnostné čísla v kontexte
Verejne dostupné benchmarky (napríklad ann-benchmarks.com a ďalšie verejné porovnania) ukazujú orientačne:
Pri záťaži okolo 1 000 QPS na zbierke 10 miliónov vektorov s 1 024 dimenziami:
pgvector: 5 000–15 000 QPS maximálne, P99 latencia variabilná podľa HWQdrant: 30 000–80 000 QPS, P99 okolo 12 msWeaviate: 25 000–50 000 QPS, P99 okolo 16 msMilvus: 100 000+ QPS s horizontálnym škálovaním, P99 okolo 18 ms (distributed setup)
Tieto čísla sú silne orientačné — skutočné výsledky závisia od dimenzionality vektorov, indexovacej stratégie (HNSW parametrov), HW (pamäť, CPU/GPU), záťažového vzoru a toho, či ide o single-tenant alebo multi-tenant záťaž. Benchmark z iného projektu je len vstupný bod pre vlastné meranie.
Mesačné náklady na cloud managed varianty sa pri typickej enterprise RAG záťaži (10 miliónov vektorov, ~1 000 QPS) pohybujú rádovo v jednotkách tisícov eur — s výraznými rozdielmi podľa poskytovateľa a regiónu. Self-host na vlastnom serveri znižuje variable cost, ale pridáva fixné náklady na prevádzku.
Kde pgvector prekvapí pozitívne
Jeden z najčastejších mýtov v prostredí SK/EU firiem: "pgvector je len prechodné riešenie pre PoC". V praxi to tak nie je. Videli sme u klientov z výroby a logistiky RAG nasadenia nad 2–3 miliónmi vektorov bežiace v produkcii na pgvector bez problémov, kde jedinou motiváciou bol existujúci PostgreSQL cluster a tím bez bandwidth na novú infra.
Kľúčové pre dobrý výkon pgvector v produkcii: HNSW index (nie IVFFlat), správna konfigurácia maintenance_work_mem pre build indexu, a partitioning ak zbierka rastie. S týmito nastaveniami pgvector zvládne väčšinu enterprise interných RAG scenárov bez prestupu.
Kde pgvector naozaj nestačí: pokročilý hybrid search, multi-vector / ColBERT retrieval, a zbierky v desiatkach miliónov, kde je výkon retrieval vrstvy kritický pre UX (sub-20ms latencia).
Integrácia s RAG frameworkmi
Všetky štyri databázy majú prvotriednú integráciu v LlamaIndex aj LangChain. LlamaIndex má natívne QdrantVectorStore, WeaviateVectorStore, PGVectorStore a MilvusVectorStore s konzistentným rozhraním — teda migrácia medzi DB je refaktor na úrovni jedného riadku konfigurácie (nie celej pipeline).
Pre výber frameworku a evaluáciu kvality RAG pipeline odkazujeme na RAG pipeline — 3 nastavenia kvality — tam sú detailne rozobrate chunking stratégie, embedding upgrade a reranking, ktoré sú nezávislé od výberu vektorovej DB.
Embedding model je samostatné rozhodnutie — pre jeho výber pozri Ako vybrať embedding model a pre hybridný search kombináciu BM25 a vektorov Hybrid search (BM25 + vektory + reranking).
Časté otázky
Môžem začať s pgvector a neskôr migrovať na Qdrant?
Áno, a je to bežný vzor. LlamaIndex abstrakcií vektorovej store je dostatočne tenká vrstva — migrácia vyžaduje reingestovanie vektorov (reindexovanie dokumentov) a zmenu konfigurácie store. Logika pipeline, chunking a embedding model zostávajú nezmenené. Pokiaľ ukladáte pôvodné texty a metadáta do relačnej DB, reingestovanie je väčšinou skript, nie mesiace práce.
Je Qdrant skutočne rýchlejší ako Weaviate pre moju záťaž?
Záleží na záťažovom vzore. Qdrant vykazuje výhodu v single-tenant scenároch s uniformnými dotazmi. Weaviate môže byť komparatívne lepší pri komplexnom multi-tenant filtrovaní, kde jeho query plánovač optimalizuje priesečník vektorového a keyword filtru. Odporúčame spustiť vlastný benchmark na representatívnej vzorke vašich dát — 1 hodina merania na vlastnom korpuse je hodnotnejšia než akýkoľvek verejný benchmark.
Potrebujeme Milvus, ak máme 50 miliónov vektorov?
Pravdepodobne nie. Qdrant a Weaviate zvládajú stovky miliónov vektorov na dobre nakonfigurovanom single-node serveri. Milvus je ospravedlnený pri miliardových zbierkach alebo pri potrebe 100 000+ QPS, kde distributed architektura naozaj prinesie úsporu. Pre 50 miliónov vektorov je Milvus skôr overhead než riešenie.
Ovplyvní výber vektorovej DB kvalitu odpovedí RAG?
Priamo málo — kvalita odpovedí závisí primárne od kvality chunkingu, embedding modelu a rerankera, nie od toho, ktorá DB vektory ukladá. Nepriamo áno: ak vektorová DB má vysokú latenciu alebo nízky recall pri filtrovanom vyhľadávaní, do generatívneho modelu prídu horšie kúsky kontextu. Výber DB ovplyvňuje predovšetkým výkon, cenu a operačnú záťaž — nie samotnú logiku retrieval pipeline.
Funguje pgvector aj pre slovenský text?
Áno — vektorová DB je jazykovo agnostická. Ukladá a vyhľadáva vektory bez ohľadu na jazyk. Jazykové vlastnosti sú zodpovednosťou embedding modelu, nie DB. Pre slovenčinu odporúčame multilingválne modely ako BGE-M3 alebo Qwen3-Embedding — viac v článku Ako vybrať embedding model.
*MP Industrial Solutions pomáha firmám navrhnúť a nasadiť RAG infraštruktúru primeranú skutočnej záťaži — od posúdenia, či pgvector nestačí, až po produkčný deployment Qdrantu alebo Weaviate na on-prem serveroch. Ak zvažujete nasadenie alebo riešite výkonnostné problémy existujúcej vektorovej vrstvy, radi si dáme úvodný hovor bez záväzkov.*