Qdrant vs Chroma vs pgvector: Výběr správné vektorové databáze pro self-hosted RAG

Qdrant vs Chroma vs pgvector: Výběr správné vektorové databáze pro self-hosted RAG

Rozhodnutí Qdrant vs Chroma vs pgvector se redukuje na trojí kompromis: rychlost šitá na míru, jednoduchost prototypování nebo setrvání v ekosystému Postgresu. Každý přístup funguje, otázkou je, který kompromis nejlépe sedí do vaší RAG pipeline.

Rychlé shrnutí: Kterou vektorovou databázi zvolit?

Zvolte Qdrant, pokud potřebujete vektorové vyhledávání produkční kvality s pokročilým filtrováním, multi-tenancy (více tenantů) a nevadí vám provozovat samostatnou službu.

Zvolte Chromu, pokud prototypujete, chcete lokální vývoj bez konfigurace nebo potřebujete přejít od nápadu k funkčnímu RAG za méně než hodinu.

Zvolte pgvector (+ pgvectorscale), pokud již provozujete PostgreSQL a chcete vektorové vyhledávání bez přidávání další infrastruktury, zejména nyní, když index StreamingDiskANN od pgvectorscale stáhl rozdíl ve výkonu.

Pokud stavíte RAG aplikaci od nuly, zbytek tohoto článku vám pomůže vybrat ten správný základ.

Výkon: Jak rychlá je každá databáze?

Výkon začne hrát roli, jakmile překročíte několik tisíc dokumentů. Zde se tyto tři možnosti významně rozcházejí.

Qdrant

Qdrant je postaven od základu pro vektorové vyhledávání. Jeho implementace v Rustu a vlastní index HNSW poskytují konzistentně nízkou latenci, benchmarky ukazují latenci dotazů kolem 94 ms i pod souběžným zatížením. Podporuje skalární, binární a produktovou kvantizaci pro kompresi vektorů a zrychlení vyhledávání při zachování recallu (úplnosti výsledků) nad 95 %.

Tam, kde Qdrant skutečně vyniká, je filtrované vyhledávání. Na rozdíl od databází, které nejprve najdou nejbližší sousedy a poté filtrují, respektuje filtrovatelný HNSW v Qdrantu omezení metadat během průchodu grafem. To znamená, že neztrácíte recall při kombinování vektorového vyhledávání s filtry, jako je category = "technical" nebo date > 2025-01-01.

Chroma

Vydání verze 1.0 přepsalo jádro Chromy do Rustu, což přineslo 3–5x rychlejší zápisy a dotazy ve srovnání s původní implementací v Pythonu. Následná aktualizace v srpnu 2025 přidala kódování vektorů do base64 pro další zvýšení throughputu o 70 %.

Pro datové sady pod milion vektorů je Chroma skutečně rychlá. Běží embedded ve vašem Python procesu bez síťové režie, což činí lokální iterace svižnými. Je to však databáze na jednom uzlu, nemá vestavěný sharding ani replikaci.

pgvector + pgvectorscale

To je černý kůň. Vanilla pgvector s HNSW je 5 250x rychlejší než sekvenční skenování a pgvector 0.8.0 přidal iterativní skenování indexu k vyřešení problému s nadměrným filtrováním, který trápil dřívější verze.

Skutečným příběhem je však pgvectorscale. Rozšíření od Timescale přidává index StreamingDiskANN, inspirovaný výzkumem DiskANN od Microsoftu, který ukládá index na disk místo do RAM. Při benchmarku 50 milionů embeddingů Cohere (768 dimenzí) dosáhl pgvectorscale 471 QPS při 99% recallu. To je 11,4x vyšší throughput než 41 QPS u Qdrantu při stejné úrovni recallu a 28x nižší p95 latence než u storage-optimalizovaného indexu Pinecone.

Háček? Tyto benchmarky používaly výkonnou instanci EC2. Vaše výsledky se budou lišit podle hardwaru. Trajektorie je však jasná: PostgreSQL již není jen „dobře dostatečnou“ volbou pro vektorové vyhledávání, je skutečně konkurenceschopný.

Verdikt: pgvector + pgvectorscale vítězí v surových číslech benchmarků. Qdrant vítězí ve výkonu filtrovaného vyhledávání. Chroma je dostatečně rychlá pro prototypy, ale není stavěna na škálování.

Nastavení a zkušenost vývojáře

Jak rychle se dostanete od nuly k vektorům?

Qdrant: Docker a Go

Qdrant potřebuje vlastní kontejner:

docker run -p 6333:6333 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant

Poté vložte vektory přes REST API nebo jeden z oficiálních SDK (Python, Rust, Go, TypeScript):

from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance

client = QdrantClient(url="http://localhost:6333")
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

Dashboard Qdrantu na adrese localhost:6333/dashboard je příjemným bonusem, můžete prohlížet kolekce, spouštět dotazy a vizuálně kontrolovat payloady. Cesta z vývoje do produkce je čistá: vaše lokální nastavení Dockeru funguje identicky na produkčním serveru nebo v Qdrant Cloud.

Chroma: pip install a hotovo

Chroma vítězí v závodě o jednoduchost s velkým náskokem:

import chromadb

client = chromadb.Client()  # In-memory, zero config
collection = client.create_collection("documents")
collection.add(
    documents=["Your RAG document here"],
    ids=["doc1"]
)

Žádný Docker. Žádný server. Dokonce automaticky generuje embeddingy, pokud neposkytnete vektory. Pro RAG prototyp se dostanete od pip install chromadb k funkčnímu vyhledávání na méně než 10 řádcích kódu.

Když budete potřebovat perzistenci, přepněte na chromadb.PersistentClient(path="./chroma_data"). Pro přístup z více procesů nebo po síti má Chroma serverový režim, ale v tu chvíli začínáte ztrácet výhodu jednoduchosti.

pgvector: Všude SQL

Pokud je Postgres již ve vašem stacku, pgvector je jedním příkazem:

CREATE EXTENSION vector;

CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

Všechno je SQL. Vaše embeddingy žijí vedle aplikačních dat ve stejné transakci. Žádná synchronizační pipeline, žádné samostatné přihlašovací údaje, žádná extra služba k monitorování. Pokud již provozujete PostgreSQL v produkci, je to cesta nejmenšího odporu.

Přidání pgvectorscale je přímočaré, pokud používáte Docker image od Timescale nebo managed poskytovatele Postgresu, který jej podporuje:

CREATE EXTENSION vectorscale;
CREATE INDEX ON documents USING diskann (embedding);

Nevýhoda? SQL není tak ergonomické jako DSL pro filtrování payloadů v Qdrantu nebo Pythonic API Chromy. A budete si muset spravovat vlastní pipeline pro embeddingy, pgvector je negeneruje za vás.

Verdikt: Chroma vítězí v nejrychlejším prototypování. pgvector vítězí, pokud je Postgres již ve vašem stacku. Qdrant má nejlepší rovnováhu mezi DX (developer experience) a připraveností na produkci.

Škálování a připravenost na produkci

Prototypování je jedna věc. Provoz RAG pipeline, která zpracovává miliony vektorů s konzistentní latencí, je věc jiná.

Qdrant: Stavěno pro horizontální škálování

Qdrant podporuje horizontální sharding out of the box. Můžete distribuovat kolekce napříč více uzly s konfigurovatelnými faktory replikace pro vysokou dostupnost. Jeho roadmapa pro rok 2026 zahrnuje oddělení čtení a zápisu a integraci blokového úložiště pro ještě lepší škálování.

Multi-tenancy je prvotřídní funkcí. Data můžete rozdělit podle tenantů pomocí filtrování založeného na payloadech bez vytváření samostatných kolekcí, což udržuje efektivní využití zdrojů. Pro systémy paměti AI agentů obsluhující více uživatelů je to významná výhoda.

Operační stránka je pevná: vestavěné zálohy, endpointy metrik pro Prometheus a obnova po havárii založená na WAL. Qdrant je navržen pro self-hosting v produkci.

Chroma: Strop jednoho uzlu

Chroma je upřímná ohledně svých limitů. Je to databáze na jednom uzlu zaměřená na jednoduchost a lokální vývoj. Nemá vestavěný sharding, replikaci ani clustering.

Chroma Cloud byla všeobecně dostupná na začátku roku 2026 jako serverless, distribuovaná managed možnost, takže můžete horizontální škálování přenechat jí místo toho, abyste ji provozovali sami. Příběh self-hosted open-source verze je však stále primárně „jeden server, jedna instance Chromy“. Pokud se váš dataset vejde na jeden stroj (až několik milionů vektorů v závislosti na dimensionalitě), je to v pořádku. Nad tuto hranici self-hosted Chroma narazí na zeď a vy budete vybírat mezi Chroma Cloud a migrací.

pgvector: Škáluje s Postgresem

pgvector dědí osvědčený příběh škálování PostgreSQL. Získáte read repliky, poolování připojení přes PgBouncer a logickou replikaci. Managed poskytovatelé jako Neon a podobné serverless Postgres platformy činí vertikální škálování téměř bez námahy.

Klíčem k odemknutí škálování je index StreamingDiskANN od pgvectorscale. Protože ukládá index na disk (SSD) místo do RAM, můžete zpracovávat datasety, které by jinak vyžadovaly drahé instance s vysokou kapacitou paměti. Při 50 milionech vektorů je již konkurenceschopný s účelově vytvořenými vektorovými databázemi.

Omezením je horizontální sharding. PostgreSQL nativně nesharduje tak jako Qdrant. Existují řešení jako Citus, ale přidávají složitost. Pro většinu self-hosted RAG workloadů pod 100 milionů vektorů je vertikální škálování s pgvectorscale dostatečné.

Verdikt: Qdrant vítězí v horizontálním škálování a multi-tenancy. pgvector vítězí ve využívání existující Postgres infrastruktury. Chroma není navržena pro produkční škálování.

Náklady na self-hosting

Všechny tři jsou open-source a zdarma ke spuštění. Skutečnou cenou je infrastruktura a inženýrský čas.

pgvector má strukturální výhodou v nákladech: pokud již platíte za Postgres, přidání vektorového vyhledávání je v podstatě zdarma, dokud nepotřebujete vyhrazené zdroje. Žádný extra kontejner, žádné extra monitorování, žádná extra strategie zálohování.

Využití zdrojů Qdrantu je efektivní vzhledem k jeho sadě funkcí, ale je to samostatná služba, budete muset započítat operační režii provozování a monitorování další části infrastruktury.

Chroma je nejlevnější ve fázi prototypu (nulová infrastruktura), ale stává se nejdražší cestou, pokud se ji pokusíte škálovat beyond to, co zvládne jeden uzel.

Pro nasazení na cloudových platformách mají Qdrant i pgvector přímočará nasazení založená na Dockeru. Chroma také funguje, ale ztrácíte embedded jednoduchost, která je jejím hlavním prodejním argumentem.

Verdikt: pgvector vítězí v celkových nákladech vlastnictví (TCO). Eliminuje celou službu z vašeho stacku. Qdrant má přiměřenou cenu za to, co nabízí. Cenový příběh Chromy funguje pouze během prototypování.

Filtrování a hybridní vyhledávání

RAG není jen „najdi nejbližší vektor“. Potřebujete kombinovat vyhledávání podobnosti s filtry metadat, rozsahy dat, řízením přístupu a někdy i hledáním klíčových slov.

Qdrant: Král filtrování

Filtrování payloadů v Qdrantu probíhá během průchodu HNSW, nikoliv po něm. To je zásadní rozdíl. Po-filtrování může snížit počet výsledků pod požadovanou hodnotu; před-filtrování zaručuje, že získáte k výsledků, které odpovídají vašim omezením.

DSL pro filtrování je expresivní:

from qdrant_client.models import Filter, FieldCondition, MatchValue

results = client.search(
    collection_name="documents",
    query_vector=embedding,
    query_filter=Filter(
        must=[
            FieldCondition(key="category", match=MatchValue(value="engineering")),
            FieldCondition(key="year", range=Range(gte=2024)),
        ]
    ),
    limit=10,
)

Qdrant také podporuje nativní hybridní vyhledávání s hustými i řídkými vektory ve stejném dotazu, což je užitečné pro kombinaci semantického porozumění s přesností klíčových slov.

Chroma: Základní, ale použitelné

Chroma podporuje filtrování metadat pomocí klauzulí where:

results = collection.query(
    query_embeddings=[embedding],
    where={"category": "engineering"},
    n_results=10,
)

Funguje to pro jednoduché případy, ale filtrování probíhá až po vektorovém vyhledávání. Při restriktivních filtrech a malých datasetech můžete získat méně výsledků, než očekáváte. Neexistuje podpora řídkých vektorů ani vestavěné hybridní vyhledávání.

pgvector: SQL je vaší supersilou

pgvector dědí plnou sílu SQL pro filtrování:

SELECT content, embedding <=> $1 AS distance
FROM documents
WHERE category = 'engineering'
  AND created_at > '2024-01-01'
  AND content @@ to_tsquery('RAG & retrieval')
ORDER BY distance
LIMIT 10;

Poslední řádek kombinuje vektorovou podobnost s vestavěným full-text vyhledáváním PostgreSQL v jediném dotazu. Není potřeba žádný externí search engine. Můžete joinovat s tabulkou uživatelů pro řízení přístupu, agregovat výsledky, používat CTE, cokoliv, co SQL umí.

Iterativní skenování v pgvector 0.8.0 také pomáhá. Pokud počáteční HNSW sken nevrátí dostatek filtrovaných výsledků, automaticky pokračuje ve vyhledávání, místo aby vrátil částečnou sadu.

Verdikt: Qdrant vítězí v komplexním filtrování metadat ve velkém měřítku. pgvector vítězí ve flexibilitě hybridního vyhledávání (SQL + full-text + vektory v jednom dotazu). Filtrování Chromy je adekvátní pouze pro prototypy.

Kdy použít kterou: Rozhodovací rámec

Zde je verze rozhodovacího stromu: Používá vaše aplikace již Postgres? Pokud ano, začněte s pgvectorem, vždy můžete migrovat později, pokud jej přerostete. Pokud ne, prototypujete nebo stavíte pro produkci? Prototypování jde na Chromu. Produkce jde na Qdrant.

Přístup „začněte jednoduše, migrujte později“ je platný, protože všechny tři podporují standardní formáty embeddingů. Přenos vektorů mezi nimi je migrace dat, nikoliv přepis architektury.

Faktor pgvectorscale: Proč Postgres dohání konkurenci

Stojí za to se u toho zastavit, protože to mění kalkulus pro mnoho týmů.

Před pgvectorscale byla hlavní výtka vůči pgvectoru vždy „funguje dobře pod milionem vektorů, ale neškáluje se“. Byla to pravda. Indexy HNSW žijí zcela v RAM a jakmile váš dataset překročí dostupnou paměť, výkon spadne ze srázu.

StreamingDiskANN mění rovnici. Uložením grafového indexu na SSD místo do RAM zvládá pgvectorscale 50 milionů vektorů při 471 QPS s 99% recalle. Statistická binární kvantizace (SBQ) komprimuje vektory s minimální ztrátou přesnosti, recall klesá z 98,6 % na 96,5 % i při agresivní kompresi.

Praktický dopad: Tým provozující RAG pipeline na Postgresu již nemusí plánovat migraci na vyhrazenou vektorovou databázi „až to bude vážné“. Pro mnoho workloadů je pgvector + pgvectorscale tou vážnou opcí.

To neznamená, že pgvectorscale je stříbrná kulka. Je to rozšíření od TigerData (dříve Timescale), takže potřebujete buď jejich Docker image, nebo poskytovatele, který jej bundleuje. Verze z roku 2026 přidala filtrované vektorové vyhledávání založené na labelách do StreamingDiskANN, inspirované výzkumem Filtered DiskANN od Microsoftu, což zužuje dlouhodobé vedení Qdrantu ve filtrovaných dotazech. Pokud však potřebujete izolaci multi-tenancy nebo nativní podporu řídkých vektorů, Qdrant stále vede.

Jak Techsy přistupuje k výběru vektorové databáze

Když stavíme RAG pipeline pro klienty, náš evaluační proces vypadá takto:

1. Audit existujícího stacku. Pokud tým již provozuje Postgres, pgvector je defaultní starting point. Nemá smysl přidávat infrastrukturní složitost, pokud pro to není jasný důvod.
2. Profilování vzorců dotazů. Silné filtrování metadat s poli vysoké kardinality? To tlačí směrem k Qdrantu. Jednoduché semantické vyhledávání? pgvector nebo Chroma stačí.
3. Odhad trajektorie škálování. Pod 5M vektorů a zůstane tam? Jakákoliv volba funguje. Plánování na 50M+? pgvectorscale nebo Qdrant, v závislosti na kroku 2.
4. Kontrola operační kapacity týmu. Dvoučlenný startup by neměl spravovat cluster Qdrantu. Managed poskytovatel Postgresu s pgvectorem je obvykle správná volba.

Postavili jsme produkční RAG systémy se všemi třemi. Upřímná odpověď zní, že výběr databáze matters méně než vaše strategie chunkingu, model embeddingů a design retrieval pipeline. Pokud trávíte více času debatováním o Qdrantu vs pgvectoru než testováním různých velikostí chunků, optimalizujete špatnou věc.

Potřebujete pomoc s návrhem RAG pipeline? Výběr vektorového úložiště a design retrievalu jsou součástí naší služby AI integrace. Ozvěte se a pomůžeme vám vybrat správný základ a postavit kolem něj vrstvu.

Často kladené otázky

Je pgvector dostatečně dobrý pro produkční RAG?

Ano, zejména s pgvectorscale. Index StreamingDiskANN zvládá 50M+ vektorů s 99% recalle při propustnosti, která v benchmarcích poráží vyhrazené vektorové databáze. Pokud již provozujete Postgres, málokdy existuje důvod přidávat samostatnou vektorovou databázi pro RAG.

Může Chroma škálovat na miliony vektorů?

Chroma zvládne několik milionů vektorů na jednom uzlu s dostatkem RAM, ale nemá vestavěné horizontální škálování. Pro datasety větší, než pojme jeden stroj, budete muset migrovat na Qdrant, pgvector nebo managed službu.

Podporuje Qdrant hybridní vyhledávání s klíčovými slovy?

Ano. Qdrant podporuje husté i řídké vektory ve stejné kolekci. Můžete spouštět hybridní dotazy, které kombinují semantickou podobnost (husté) s匹配 klíčových slov (řídké) a kontrolovat vážení mezi nimi.

Kolik RAM potřebuji pro každou databázi?

Záleží na počtu vektorů a dimenzích. Jako hrubý odhad: 1M vektorů o 1536 dimenzích zabere asi 6 GB v Qdrantu nebo pgvectoru s HNSW. Chroma používá o něco více kvůli overheadu Pythonu. Index DiskANN od pgvectorscale dramaticky snižuje nároky na RAM uložením indexu na SSD.

Mohu mezi těmito databázemi později migrovat?

Ano. Všechny tři pracují se standardními float poli, takže vektory jsou přenosné. Budete muset znovu vytvořit indexy a přizpůsobit vrstvu dotazů, ale jde o migraci dat, nikoliv přepis. Většina migračních nástrojů, jako je oficiální migrační nástroj Qdrantu, to zjednodušuje.

Který nejlépe funguje s LangChain a LlamaIndex?

Všechny tři mají oficiální integrace s LangChain a LlamaIndex. Chroma je často defaultní v tutoriálech, což ji činí nejhladší pro začátek. Integrace Qdrantu a pgvectoru jsou stejně zralé pro produkční použití. Podívejte se na našeho průvodce nejlepšími RAG nástroji pro širší pohled na ekosystém.

Mám použít pgvector nebo pgvectorscale?

Použijte oba. pgvector poskytuje základní typ vector a index HNSW. pgvectorscale přidává na vrstvu StreamingDiskANN pro lepší výkon při škálování. Jsou to doplňková rozšíření, nikoliv alternativy.

Je Qdrant zdarma pro self-hosting?

Zcela zdarma pod licencí Apache 2.0. Qdrant Cloud je placená managed možnost, začínající s free tierem 1 GB. Pro self-hosting platíte pouze za compute infrastrukturu.

Co třeba Milvus nebo Weaviate?

Obě jsou solidní alternativy. Milvus je silnější ve velmi velkém měřítku (miliardy+ vektorů) s akcelerací GPU. Weaviate má pěknou vestavěnou pipeline pro vectorizaci. Ale pro self-hosted RAG pod 100M vektorů pokrývají Qdrant, Chroma a pgvector drtivou většinu use casů s menší operační složitostí.

Zvládne pgvector souběžné RAG dotazy v produkci?

Ano. PostgreSQL je navržen pro souběžné workloady. pgvector dědí poolování připojení (PgBouncer), read repliky a MVCC kontrolu konkurence. Pro high-throughput RAG párujte pgvector s connection poolerem a vylaďte shared_buffers a effective_cache_size.

Finální verdikt

Celkově: Pro většinu self-hosted RAG pipeline je pgvector + pgvectorscale pragmatickou volbou. Je dostatečně rychlý, škáluje se na desítky milionů vektorů a udržuje váš stack jednoduchý. Již znáte SQL. Váš tým již spravuje Postgres. Jedna služba méně znamená jednu věc méně, která se může rozbít ve 2 ráno.

Pokud potřebujete pokročilé filtrované vyhledávání, multi-tenancy nebo stavíte produkt, kde je vektorové vyhledávání klíčovou funkcí (nikoliv podpůrnou schopností), Qdrant je správná investice. Je to nejkomplexnější open-source vektorová databáze z dobrého důvodu.

Chroma si zasluhuje své místo jako nástroj pro prototypování. Použijte ji k validaci vašeho RAG přístupu, testování různých strategií chunkingu a iteraci nad kvalitou retrievalu. Když budete připraveni na produkci, migrujte na kteroukoli z ostatních dvou, která sedí do vašeho stacku.

Nejlepší rada? Přestaňte debatovat a začněte stavět. Zvolte pgvector, pokud máte Postgres, Qdrant, pokud ne, a rozchoďte svou RAG pipeline. Vektorové úložiště můžete vždy vyměnit později, model embeddingů, strategie chunkingu a logika retrievalu matters mnohem více.

Zdroje

• Benchmarky Qdrantu
• Vydání Chromy 1.0: 4x rychlejší
• pgvectorscale: StreamingDiskANN pro PostgreSQL
• pgvector je nyní rychlejší než Pinecone za 75 % ceny
• pgvector 0.8.0: Iterativní skenování indexu
• Ceník Qdrantu