Qdrant vs Chroma vs pgvector: Välja rätt vektordatabas för självhostad RAG

Qdrant vs Chroma vs pgvector: Välja rätt vektordatabas för självhostad RAG

Beslutet Qdrant vs Chroma vs pgvector handlar om en trevägs avvägning: ändamålsbyggd hastighet, prototypenkelhet, eller att stanna kvar i Postgres-ekosystemet. Varje ansats fungerar, frågan är vilken avvägning som passar din RAG-pipeline.

Snabbsammanfattning: Vilken vektordatabas bör du välja?

Välj Qdrant om du behöver produktionsklassad vektorsökning med avancerad filtrering, multi-tenancy, och inte har något emot att köra en separat tjänst.

Välj Chroma om du prototypar, vill ha nollkonfiguration lokal utveckling, eller behöver gå från idé till fungerande RAG på under en timme.

Välj pgvector (+ pgvectorscale) om du redan kör PostgreSQL och vill ha vektorsökning utan att lägga till infrastruktur, speciellt nu när pgvectorscales StreamingDiskANN-index stängt prestationsgapet.

Om du bygger en RAG-applikation från grunden hjälper resten av det här inlägget dig att välja rätt grund.

Prestanda: Hur snabb är varje databas?

Prestanda spelar roll när du går bortom några tusen dokument. Här är var dessa tre skiljer sig markant.

Qdrant

Qdrant är byggt från grunden för vektorsökning. Dess Rust-implementering och anpassade HNSW-index levererar konsekvent låg latens, benchmarks visar frågelatens runt 94 ms även under samtidig last. Det stöder skalär, binär och produktkvantisering för att komprimera vektorer och snabba upp sökning medan recall hålls över 95%.

Där Qdrant verkligen lyser är filtrerad sökning. Till skillnad från databaser som hittar närmaste grannar först och sedan filtrerar, respekterar Qdrants filterbara HNSW metadatabegränsningar under graftraversering. Det innebär att du inte förlorar recall när du kombinerar vektorsökning med filter som category = "technical" eller date > 2025-01-01.

Chroma

Chromas version 1.0 skrev om kärnan i Rust, vilket gav 3-5x snabbare skrivningar och frågor jämfört med den ursprungliga Python-implementeringen. En uppföljningsuppdatering i augusti 2025 lade till base64-vektorkodning för ytterligare 70% genomströmningsökning.

För dataset under en miljon vektorer är Chroma genuint snabbt. Det körs inbäddat i din Python-process utan nätverksoverhead, vilket gör lokal iteration smidig. Men det är en enkelnodsdatabas, ingen inbyggd sharding eller replikering.

pgvector + pgvectorscale

Det här är outsiderna. Vanlig pgvector med HNSW är 5 250 gånger snabbare än en sekventiell skanning, och pgvector 0.8.0 lade till iterativ indexskanning för att lösa överfiltreringsproblemet som plågade tidigare versioner.

Men den verkliga historien är pgvectorscale. Timescales tillägg lägger till StreamingDiskANN-indexet, inspirerat av Microsofts DiskANN-forskning, som lagrar indexet på disk istället för RAM. På ett benchmark med 50 miljoner Cohere-embeddings (768 dimensioner) uppnådde pgvectorscale 471 QPS vid 99% recall. Det är 11,4 gånger högre genomströmning än Qdrants 41 QPS vid samma recall-nivå, och 28 gånger lägre p95-latens än Pinecones lagringsoptimerade index.

Nackdelen? Dessa benchmarks använde en kraftfull EC2-instans. Dina resultat beror på hårdvara. Men trenden är tydlig: PostgreSQL är inte längre "bra-nog"-alternativet för vektorsökning, det är genuint konkurrenskraftigt.

Verdict: pgvector + pgvectorscale vinner på råa benchmarktal. Qdrant vinner på filtrerad sökprestanda. Chroma är snabbt nog för prototyper men är inte byggt för skala.

Installation och utvecklarupplevelse

Hur snabbt kan du gå från noll till vektorer?

Qdrant: Docker och kör

Qdrant behöver sin egen container:

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

Lägg sedan till vektorer via REST-API:t eller ett av de officiella SDK:erna (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),
)

Qdrants dashboard på localhost:6333/dashboard är ett trevligt inslag, du kan bläddra igenom samlingar, köra frågor och inspektera payloads visuellt. Vägen från dev till produktion är ren: din lokala Docker-setup fungerar identiskt på en produktionsserver eller Qdrant Cloud.

Chroma: pip install och klart

Chroma vinner enkelhetsracet med bred marginal:

import chromadb

client = chromadb.Client()  # I minnet, nollkonfiguration
collection = client.create_collection("documents")
collection.add(
    documents=["Ditt RAG-dokument här"],
    ids=["doc1"]
)

Ingen Docker. Ingen server. Det hanterar till och med embedding-generering automatiskt om du inte tillhandahåller vektorer. För en RAG-prototyp kan du gå från pip install chromadb till fungerande sökning på under 10 rader.

När du är redo för persistens, byt till chromadb.PersistentClient(path="./chroma_data"). För åtkomst från flera processer eller över nätverk har Chroma ett serverläge, men då börjar du förlora enkelhetsförsprånget.

pgvector: SQL hela vägen

Om Postgres redan finns i ditt stack är pgvector en enda rad:

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);

Allt är SQL. Dina embeddings lever bredvid dina applikationsdata i samma transaktion. Ingen synkroniseringspipeline, inga separata uppgifter, ingen extra tjänst att övervaka. Om du redan kör PostgreSQL i produktion är detta vägen med minst motstånd.

Att lägga till pgvectorscale ovanpå är enkelt om du använder Timescales Docker-image eller en hanterad Postgres-leverantör som stöder det:

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

Nackdelen? SQL är inte lika ergonomiskt som Qdrants payload-filtreringsDSL eller Chromas Pythoneskt API. Och du måste hantera din egen embedding-pipeline, pgvector genererar inte embeddings åt dig.

Verdict: Chroma vinner för snabbaste prototyp. pgvector vinner om Postgres redan finns i ditt stack. Qdrant har den bästa balansen mellan utvecklarupplevelse och produktionsmognad.

Skalning och produktionsmognad

Prototypande är en sak. Att köra en RAG-pipeline som hanterar miljoner vektorer med konsekvent latens är en annan.

Qdrant: Byggt för horisontell skalning

Qdrant stöder horisontell sharding direkt ur lådan. Du kan distribuera samlingar över flera noder, med konfigurerbara replikeringsfaktorer för hög tillgänglighet. Dess roadmap för 2026 inkluderar läs-skriv-segregation och blocklagringsintegration för ännu bättre skalning.

Multi-tenancy är en förstklassig funktion. Du kan partitionera data per hyresgäst med payload-baserad filtrering utan att skapa separata samlingar, vilket håller resursanvändningen effektiv. För AI-agentminne system som hanterar flera användare är detta en meningsfull fördel.

Den operativa profilen är solid: inbyggda säkerhetskopieringar, metriks-ändpunkter för Prometheus, och WAL-baserad kraschåterställning. Qdrant är designat för att vara självhostat i produktion.

Chroma: Enodnsgräns

Chroma är ärlig om sina begränsningar. Det är en enkelnodsdatabas fokuserad på enkelhet och lokal utveckling. Ingen inbyggd sharding, ingen replikering, ingen klustring.

Chroma Cloud blev allmänt tillgängligt i början av 2026 som ett serverlöst, distribuerat hanterat alternativ, men den självhostade historien är i huvudsak "en server, en Chroma-instans." Om ditt dataset ryms på en enda maskin (upp till några miljoner vektorer beroende på dimensionalitet) är det okej. Bortom det stöter du på en vägg.

pgvector: Skalar med Postgres

pgvector ärver PostgreSQLs beprövade skalningshistoria. Du får läsrepliker, connection pooling via PgBouncer och logisk replikering. Hanterade leverantörer som Neon och liknande serverlösa Postgres-plattformar gör vertikal skalning nästan ansträngningsfri.

pgvectorscales StreamingDiskANN-index är nyckeln för skalning. Eftersom det lagrar grafindexet på SSD:er istället för RAM kan du hantera dataset som annars skulle kräva dyra minneskrävande instanser. Vid 50 miljoner vektorer är det redan konkurrenskraftigt med dedikerade vektordatabaser.

Begränsningen är horisontell sharding. PostgreSQL shardar inte nativt som Qdrant. Lösningar som Citus finns men lägger till komplexitet. För de flesta självhostade RAG-arbetsbelastningar under 100M vektorer är vertikal skalning med pgvectorscale tillräckligt.

Verdict: Qdrant vinner för horisontell skalning och multi-tenancy. pgvector vinner för att utnyttja befintlig Postgres-infrastruktur. Chroma är inte designat för produktionsskala.

Kostnad för självhosting

Alla tre är open-source och gratis att köra. Den verkliga kostnaden är infrastruktur och ingenjörstid.

pgvector har en strukturell kostnadsfördel: om du redan betalar för Postgres är det i princip gratis att lägga till vektorsökning tills du behöver dedikerade resurser. Ingen extra container, ingen extra övervakning, ingen extra säkerhetskopieringsstrategi.

Qdrants resursanvändning är effektiv för dess funktionsuppsättning, men det är en separat tjänst, du måste räkna in den operativa overhead av att köra och övervaka ytterligare en infrastrukturdel.

Chroma är billigast i prototypfasen (noll infrastruktur) men blir den dyraste vägen om du försöker skala det bortom vad en enda nod kan hantera.

För distribution på molnplattformar har Qdrant och pgvector båda enkla Docker-baserade distributioner. Chroma fungerar också, men du förlorar den inbäddade enkelheten som är dess största försäljningsargument.

Verdict: pgvector vinner på total ägandekostnad (TCO). Det eliminerar en hel tjänst från ditt stack. Qdrant är rimligt prissatt för vad det erbjuder. Chromas kostnadsprofil fungerar bara under prototypande.

Filtrering och hybridsökning

RAG är inte bara "hitta närmaste vektorn." Du behöver kombinera likhetssökning med metadatafilter, datumintervall, åtkomstkontroller och ibland nyckelordsmatchning.

Qdrant: Filtreringskungen

Qdrants payload-filtrering sker under HNSW-traverseringen, inte efteråt. Det är en kritisk distinktion. Efterfiltrering kan minska ditt resultatantal under vad du begärt; förfiltrering garanterar att du får k resultat som matchar dina begränsningar.

FiltreringsDSL:et är uttrycksfullt:

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 stöder också nativ hybridsökning med både täta och glesa vektorer i samma fråga, vilket är användbart för att kombinera semantisk förståelse med nyckelordsprecision.

Chroma: Grundläggande men användbart

Chroma stöder metadatafiltrering med where-satser:

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

Det fungerar för enkla fall, men filtrering sker efter vektorsökningen. Med restriktiva filter och små dataset kan du få färre resultat än förväntat. Det finns inget stöd för glesa vektorer eller inbyggd hybridsökning.

pgvector: SQL är din superkraft

pgvector ärver SQL:s fulla kraft för filtrering:

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;

Den sista raden kombinerar vektorlikhet med PostgreSQLs inbyggda fulltextsökning i en enda fråga. Ingen extern sökmotor behövs. Du kan joina mot din användartabell för åtkomstkontroll, aggregera resultat, använda CTE:er, allt SQL kan göra.

pgvector 0.8.0:s iterativa skanning hjälper också. Om den initiala HNSW-skanningen inte returnerar tillräckligt med filtrerade resultat fortsätter den automatiskt söka istället för att returnera en partiell uppsättning.

Verdict: Qdrant vinner för komplex metadatafiltrering i stor skala. pgvector vinner för hybridsökflexibilitet (SQL + fulltext + vektor i en fråga). Chromas filtrering räcker bara till för prototyper.

När man ska använda vilken: Beslutsramverk

Här är beslutsträdsversionen: Använder din app redan Postgres? Om ja, börja med pgvector, du kan alltid migrera senare om du växt ur det. Om nej, prototypar du eller bygger för produktion? Prototyp går mot Chroma. Produktion går mot Qdrant.

Ansatsen "börja enkelt, migrera senare" är giltig eftersom alla tre stöder standardembeddingformat. Att flytta vektorer mellan dem är en datamigrering, inte en arkitekturomskrivning.

pgvectorscale-faktorn: Varför Postgres tar ikapp

Värt att dröja vid här eftersom det förändrar kalkylen för många team.

Före pgvectorscale var kritiken mot pgvector alltid "det fungerar bra under en miljon vektorer, men det skalar inte." Det stämde. HNSW-index lever helt i RAM, och när ditt dataset överstiger tillgängligt minne faller prestandan dramatiskt.

StreamingDiskANN förändrar ekvationen. Genom att lagra grafindexet på SSD istället för RAM hanterar pgvectorscale 50 miljoner vektorer vid 471 QPS med 99% recall. Statistisk binär kvantisering (SBQ) komprimerar vektorer med minimal noggrannhetsförlust, recall sjunker från 98,6% till 96,5% även med aggressiv komprimering.

Den praktiska effekten: ett team som kör en RAG-pipeline på Postgres behöver inte längre planera en migrering till en dedikerad vektordatabas "när det blir seriöst." För många arbetsbelastningar är pgvector + pgvectorscale det seriösa alternativet.

Det sagt, pgvectorscale är ingen universallösning. Det är ett tillägg från TigerData (tidigare Timescale), så du behöver antingen deras Docker-image eller en leverantör som inkluderar det. En release under 2026 lade till etikettbaserad filtrerad vektorsökning i StreamingDiskANN (inspirerad av Microsofts Filtered DiskANN-forskning), vilket krymper Qdrants långvariga försprång på filtrerade frågor. Men om du behöver multi-tenant isolering eller inbyggt stöd för glesa vektorer har Qdrant fortfarande övertaget.

Hur Techsy hanterar val av vektordatabas

När vi bygger RAG-pipelines för kunder ser vår utvärderingsprocess ut så här:

1. Granska befintliga stack. Om teamet redan kör Postgres är pgvector standardstartpunkten. Det finns ingen poäng med att lägga till infrastrukturkomplexitet utan en tydlig anledning.
2. Profilera frågemönster. Tung metadatafiltrering med högt kardinalitetsfält? Det pekar mot Qdrant. Enkel semantisk sökning? pgvector eller Chroma räcker.
3. Uppskatta skalningsbanan. Under 5M vektorer och stannar där? Vilket alternativ som helst fungerar. Planerar 50M+? pgvectorscale eller Qdrant, beroende på steg 2.
4. Kontrollera teamets ops-kapacitet. En tvåpersoners startup bör inte hantera ett Qdrant-kluster. En hanterad Postgres-leverantör med pgvector är vanligtvis rätt val.

Vi har byggt produktions-RAG-system med alla tre. Det ärliga svaret är att databasval spelar mindre roll än din chunking-strategi, embeddingmodell och utformning av återvinningspipeline. Om du lägger mer tid på att debattera Qdrant vs pgvector än på att testa olika chunkstorlekar optimerar du fel sak.

Behöver du hjälp med att utforma en RAG-pipeline? Val av vektorlager och design av återvinning ingår i vår AI-integrationstjänst. Kontakta oss så hjälper vi dig välja rätt grund och bygga lagret runt den.

Vanliga frågor

Är pgvector tillräckligt bra för produktions-RAG?

Ja, speciellt med pgvectorscale. StreamingDiskANN-indexet hanterar 50M+ vektorer med 99% recall vid genomströmningsnivåer som slår dedikerade vektordatabaser i benchmarks. Om du redan kör Postgres finns det sällan anledning att lägga till en separat vektordatabas för RAG.

Kan Chroma skalas till miljoner vektorer?

Chroma kan hantera ett par miljoner vektorer på en enda nod med tillräckligt RAM, men det har ingen inbyggd horisontell skalning. För dataset bortom vad en enda maskin kan hålla behöver du migrera till Qdrant, pgvector, eller en hanterad tjänst.

Stöder Qdrant hybridsökning med nyckelord?

Ja. Qdrant stöder både täta och glesa vektorer i samma samling. Du kan köra hybridfrågor som kombinerar semantisk likhet (tät) med nyckelordsmatchning (gles) och kontrollera viktningen mellan dem.

Hur mycket RAM behöver jag för varje databas?

Det beror på vektorantal och dimensioner. Som ungefärlig guide: 1M vektorer vid 1 536 dimensioner tar ungefär 6 GB i Qdrant eller pgvector med HNSW. Chroma använder något mer på grund av Python-overhead. pgvectorscales DiskANN-index minskar dramatiskt RAM-behovet genom att lagra indexet på SSD.

Kan jag migrera mellan dessa databaser senare?

Ja. Alla tre arbetar med standardfloat-arrayer, så vektorer är portabla. Du behöver återskapa index och anpassa ditt frågeskikt, men det är en datamigrering, inte en omskrivning. De flesta migreringsverktyg som Qdrants officiella migreringsverktyg förenklar detta.

Vilken fungerar bäst med LangChain och LlamaIndex?

Alla tre har officiella integrationer med LangChain och LlamaIndex. Chroma är ofta standard i handledningar, vilket gör det smidigast att komma igång med. Qdrant- och pgvector-integrationer är lika mogna för produktionsanvändning. Kolla vår guide om de bästa RAG-verktygen för en bredare bild av ekosystemet.

Ska jag använda pgvector eller pgvectorscale?

Använd båda. pgvector tillhandahåller den grundläggande vector-typen och HNSW-indexet. pgvectorscale lägger till StreamingDiskANN ovanpå för bättre prestanda i stor skala. De är kompletterande tillägg, inte alternativ.

Är Qdrant gratis att självhosta?

Helt gratis under Apache 2.0-licensen. Qdrant Cloud är det betalda hanterade alternativet, med ett gratis 1 GB-nivå som startpunkt. För självhosting betalar du bara för beräkningsinfrastrukturen.

Vad sägs om Milvus eller Weaviate?

Båda är solida alternativ. Milvus är starkare vid mycket stor skala (miljarder+ vektorer) med GPU-acceleration. Weaviate har en snygg inbyggd vektoriseringspipeline. Men för självhostad RAG under 100M vektorer täcker Qdrant, Chroma och pgvector den stora majoriteten av användningsfall med mindre operativ komplexitet.

Kan pgvector hantera samtidiga RAG-frågor i produktion?

Ja. PostgreSQL är designat för samtidiga arbetsbelastningar. pgvector ärver connection pooling (PgBouncer), läsrepliker och MVCC-konkurrensstyrning. För hög genomströmning RAG, koppla pgvector med en connection pooler och finjustera shared_buffers och effective_cache_size.

Slutligt omdöme

Sammantaget: För de flesta självhostade RAG-pipelines är pgvector + pgvectorscale det pragmatiska valet. Det är snabbt nog, skalar till tiotals miljoner vektorer, och håller ditt stack enkelt. Du kan SQL redan. Ditt team hanterar Postgres redan. En tjänst mindre betyder en sak mindre som kan gå sönder klockan 2 på natten.

Om du behöver avancerad filtrerad sökning, multi-tenancy, eller bygger en produkt där vektorsökning är kärnfunktionen (inte en stödjande förmåga), är Qdrant rätt investering. Det är den mest fullständiga open-source-vektordatabasen av en anledning.

Chroma förtjänar sin plats som prototypverktyg. Använd det för att validera din RAG-ansats, testa olika chunking-strategier och iterera på återvinningskvalitet. När du är redo för produktion, migrera till vilken av de andra två som passar ditt stack.

Det bästa rådet? Sluta debattera och börja bygga. Välj pgvector om du har Postgres, Qdrant om du inte har det, och få din RAG-pipeline att fungera. Du kan alltid byta vektorlager senare, embeddingmodellen, chunk-strategin och återvinningslogiken spelar mycket större roll.

Källor

• Qdrant Benchmarks
• Chroma 1.0 Release: 4x Faster
• pgvectorscale: StreamingDiskANN for PostgreSQL
• pgvector Is Now Faster than Pinecone at 75% Less Cost
• pgvector 0.8.0: Iterative Index Scanning
• Qdrant Pricing