Qdrant vs Chroma vs pgvector: Valg af den rigtige vektordatabase til selvhostet RAG

Qdrant vs Chroma vs pgvector: Valg af den rigtige vektordatabase til selvhostet RAG

Beslutningen Qdrant vs Chroma vs pgvector handler i bund og grund om en trevejs afvejning: hastighed bygget specifikt til formålet, enkelhed ved prototyping, eller at blive inden for Postgres-økosystemet. Hver tilgang virker; spørgsmålet er, hvilken afvejning der passer bedst til din RAG-pipeline.

Hurtigt overblik: Hvilken vektordatabase skal du vælge?

Vælg Qdrant, hvis du har brug for vektorsøgning i produktionskvalitet med avanceret filtrering, multi-tenancy, og du ikke har noget imod at køre en separat service.

Vælg Chroma, hvis du laver prototyper, ønsker lokal udvikling uden konfiguration, eller skal gå fra idé til fungerende RAG på under en time.

Vælg pgvector (+ pgvectorscale), hvis du allerede kører PostgreSQL og ønsker vektorsøgning uden at tilføje infrastruktur, især nu hvor pgvectorscales StreamingDiskANN-indeks har lukket gab i ydeevnen.

Hvis du bygger en RAG-applikation fra bunden, vil resten af dette indlæg hjælpe dig med at vælge det rette fundament.

Ydeevne: Hvor hurtig er hver database?

Ydeevne bliver afgørende, når du går ud over et par tusinde dokumenter. Her divergerer de tre løsninger markant.

Qdrant

Qdrant er bygget fra grunden til vektorsøgning. Dens Rust-implementering og tilpassede HNSW-indeks leverer konsekvent lav latenstid; benchmarks viser en query-latenstid på omkring 94 ms, selv under samtidig belastning. Det understøtter scalar, binary og product kvantisering for at komprimere vektorer og fremskynde søgningen, mens recall holdes over 95 %.

Hvor Qdrant virkelig skinner, er i filtreret søgning. I modsætning til databaser, der først finder nærmeste naboer og derefter filtrerer, respekterer Qdrants filterbare HNSW metadata-begrænsninger under graf-traverseringen. Det betyder, at du ikke mister recall, når du kombinerer vektorsøgning med filtre som category = "technical" eller date > 2025-01-01.

Chroma

Chromas 1.0-release omskrev kernen i Rust, hvilket leverede 3-5 gange hurtigere writes og queries sammenlignet med den oprindelige Python-implementering. En opfølgende opdatering i august 2025 tilføjede base64-vektorkodning for endnu et 70 % boost i throughput.

For datasæt under en million vektorer er Chroma ægte hurtigt. Det kører integreret i din Python-proces uden netværksoverhead, hvilket gør lokal iteration lynhurtig. Men det er en enkelt-node database; der er ingen indbygget sharding eller replikering.

pgvector + pgvectorscale

Dette er den mørke hest. Vanilje-pgvector med HNSW er 5.250 gange hurtigere end en sekventiel scanning, og pgvector 0.8.0 tilføjede iterativ indeks-scanning for at løse problemet med overfiltrering, der plagede tidligere versioner.

Men den egentlige historie er pgvectorscale. Timescales udvidelse tilføjer StreamingDiskANN-indekset, inspireret af Microsofts DiskANN-forskning, som gemmer indekset på disk i stedet for i RAM. På et benchmark med 50 millioner Cohere-embeddings (768 dimensioner) ramte pgvectorscale 471 QPS ved 99 % recall. Det er 11,4 gange højere throughput end Qdrants 41 QPS på samme recall-niveau og 28 gange lavere p95-latenstid end Pinecones storage-optimerede indeks.

Hagen ved det? Disse benchmarks brugte en kraftig EC2-instans. Dine resultater afhænger af hardwaren. Men tendensen er klar: PostgreSQL er ikke længere bare "god nok" til vektorsøgning; det er reelt konkurrencedygtigt.

Konklusion: pgvector + pgvectorscale vinder på rå benchmark-tal. Qdrant vinder på ydeevne ved filtreret søgning. Chroma er hurtigt nok til prototyper, men er ikke bygget til skala.

Opsætning og udvikleroplevelse

Hvor hurtigt kan du komme fra nul til vektorer?

Qdrant: Docker og Go

Qdrant kræver sin egen container:

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

Indsæt derefter vektorer via REST API'et eller en af de officielle SDK'er (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 er en fin detalje; du kan browse collections, køre queries og inspicere payloads visuelt. Vejen fra udvikling til produktion er ren: dit lokale Docker-setup fungerer identisk på en produktionsserver eller i Qdrant Cloud.

Chroma: pip install og færdig

Chroma vinder simplicitetsløbet med stor margin:

import chromadb

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

Ingen Docker. Ingen server. Det håndterer endda generering af embeddings automatisk, hvis du ikke leverer vektorer. Til en RAG-prototype kan du gå fra pip install chromadb til en fungerende søgning på under 10 linjer kode.

Når du er klar til persistens, skal du blot skifte til chromadb.PersistentClient(path="./chroma_data"). Til multi-process eller netværksadgang har Chroma en servertilstand, men på det tidspunkt begynder du at miste fordelene ved simplicitet.

pgvector: SQL hele vejen

Hvis Postgres allerede er i din stack, er pgvector en one-liner:

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

Alt er SQL. Dine embeddings lever side om side med dine applikationsdata i samme transaktion. Der er ingen sync-pipeline, ingen separate credentials, ingen ekstra service at overvåge. Hvis du allerede kører PostgreSQL i produktion, er dette vejen med mindst modstand.

Det er ligetil at tilføje pgvectorscale oveni, hvis du bruger Timescales Docker-image eller en managed Postgres-udbyder, der understøtter det:

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

Ulempen? SQL er ikke lige så ergonomisk som Qdrants DSL til payload-filtrering eller Chromas Pythonic API. Og du skal administrere din egen embedding-pipeline; pgvector genererer ikke embeddings for dig.

Konklusion: Chroma vinder for hurtigste prototype. pgvector vinder, hvis Postgres allerede er i din stack. Qdrant har den bedste balance mellem DX (Developer Experience) og produktionsklarhed.

Skalering og produktionsklarhed

Prototyping er én ting. At køre en RAG-pipeline, der håndterer millioner af vektorer med konsistent latenstid, er en anden.

Qdrant: Bygget til horisontal skalering

Qdrant understøtter horisontal sharding out of the box. Du kan distribuere collections på tværs af flere noder med konfigurerbare replikeringsfaktorer for høj tilgængelighed. Dens roadmap for 2026 inkluderer adskillelse af læs/skriv og integration af blok-storage for endnu bedre skalering.

Multi-tenancy er en førsteklasses funktion. Du kan partitionere data efter tenant ved hjælp af payload-baseret filtrering uden at oprette separate collections, hvilket holder ressourceforbruget effektivt. For AI agent-hukommelsessystemer, der håndterer flere brugere, er dette en betydelig fordel.

Den operationelle historie er solid: indbyggede backups, metrics-endpoints til Prometheus og WAL-baseret crash recovery. Qdrant er designet til at blive selvhostet i produktion.

Chroma: Loft for enkelt-node

Chroma er ærlig omkring sine begrænsninger. Det er en enkelt-node database fokuseret på simplicitet og lokal udvikling. Der er ingen indbygget sharding, ingen replikering og ingen clustering.

Chroma Cloud blev generelt tilgængelig i begyndelsen af 2026 som en serverless, distribueret managed mulighed, så du kan outsource horisontal skalering der i stedet for at køre det selv. Men historien om selvhosting og open source er stadig primært "én server, én Chroma-instans". Hvis dit datasæt passer på en enkelt maskine (op til et par millioner vektorer afhængigt af dimensionalitet), er det fint. Ud over det rammer selvhostet Chroma en mur, og du står med valget mellem Chroma Cloud og en migration.

pgvector: Skalerer med Postgres

pgvector arver PostgreSQLs battle-testede skaleringshistorie. Du får read-replikas, connection pooling via PgBouncer og logisk replikering. Managed udbydere som Neon og lignende serverless Postgres-platforme gør vertikal skalering næsten umiddelbar.

pgvectorscales StreamingDiskANN-indeks er nøglen til at låse op for skala. Fordi det gemmer indekset på disk (SSD'er) frem for i RAM, kan du håndtere datasæt, der ellers ville kræve dyre high-memory instanser. Ved 50 millioner vektorer er det allerede konkurrencedygtigt med specialiserede vektordatabaser.

Begrænsningen er horisontal sharding. PostgreSQL sharder ikke nativt som Qdrant gør. Løsninger som Citus eksisterer, men tilføjer kompleksitet. For de fleste selvhostede RAG-workloads under 100 millioner vektorer er vertikal skalering med pgvectorscale tilstrækkelig.

Konklusion: Qdrant vinder på horisontal skalering og multi-tenancy. pgvector vinder på brugen af eksisterende Postgres-infrastruktur. Chroma er ikke designet til produktionsskala.

Omkostninger ved selvhosting

Alle tre er open source og gratis at køre. De reelle omkostninger er infrastruktur og ingeniørtid.

pgvector har en strukturel omkostningsfordel: hvis du allerede betaler for Postgres, er tilføjelsen af vektorsøgning stort set gratis, indtil du har brug for dedikerede ressourcer. Der er ingen ekstra container, ingen ekstra overvågning, ingen ekstra backup-strategi.

Qdrants ressourceforbrug er effektivt i forhold til dets funktionalitet, men det er en separat service; du skal medregne det operationelle overhead ved at køre og overvåge endnu et stykke infrastruktur.

Chroma er billigst i prototypefasen (nul infrastruktur), men bliver den dyreste vej, hvis du forsøger at skalere det ud over, hvad en enkelt node kan håndtere.

Ved deployering på cloud-platforme har både Qdrant og pgvector ligefrem Docker-baserede deployeringer. Chroma virker også, men du mister den indlejrede simplicitet, som er dets største salgsargument.

Konklusion: pgvector vinder på total ejerskabsomkostning (TCO). Det eliminerer en hel service fra din stack. Qdrant er rimeligt prissat for det, det tilbyder. Chromas omkostningsprofil fungerer kun under prototyping.

Filtrering og hybrid søgning

RAG er ikke bare "find den nærmeste vektor". Du skal kombinere lighedssøgning med metadata-filtre, datointervaller, adgangskontrol og nogle gange keyword-matching.

Qdrant: Filtreringskongen

Qdrants payload-filtrering sker under HNSW-traverseringen, ikke bagefter. Det er en kritisk forskel. Post-filtrering kan få dit antal resultater til at falde under det, du bad om; pre-filtrering garanterer, at du får k resultater, der matcher dine begrænsninger.

Filtrerings-DSL'en er udtryksfuld:

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 understøtter også native hybrid søgning med både dense og sparse vektorer i samme query, hvilket er nyttigt til at kombinere semantisk forståelse med keyword-præcision.

Chroma: Basalt, men brugbart

Chroma understøtter metadata-filtrering med where-sætninger:

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

Det virker til simple tilfælde, men filtreringen sker efter vektorsøgningen. Med restriktive filtre og små datasæt kan du ende med færre resultater end forventet. Der er ingen understøttelse af sparse vektorer eller indbygget hybrid søgning.

pgvector: SQL er din superkraft

pgvector arver hele kraften i SQL til 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 sidste linje kombinerer vektorlighed med PostgreSQLs indbyggede fuldtekstsøgning i en enkelt query. Ingen ekstern søgemaskine nødvendig. Du kan joine mod din users-tabel for adgangskontrol, aggregere resultater, bruge CTE'er – alt, hvad SQL kan gøre.

pgvector 0.8.0s iterative scanning hjælper også. Hvis den indledende HNSW-scanning ikke returnerer nok filtrerede resultater, fortsætter den automatisk med at søge i stedet for at returnere et delvist sæt.

Konklusion: Qdrant vinder på kompleks metadata-filtrering i skala. pgvector vinder på fleksibilitet i hybrid søgning (SQL + fuldtekst + vektor i én query). Chromas filtrering er kun tilstrækkelig til prototyper.

Hvornår skal du bruge hvad: Beslutningsframework

Her er beslutningstræ-versionen: Bruger din app allerede Postgres? Hvis ja, start med pgvector; du kan altid migrere senere, hvis du vokser ud af det. Hvis nej, laver du prototyper eller bygger til produktion? Prototyping går til Chroma. Produktion går til Qdrant.

Tilgangen "start simpelt, migrér senere" er valid, fordi alle tre understøtter standard embedding-formater. At flytte vektorer mellem dem er en datamigration, ikke en arkitektonisk omskrivning.

pgvectorscale-faktoren: Hvorfor Postgres haler ind

Det er værd at dvæle ved dette, fordi det ændrer kalkulen for mange teams.

Før pgvectorscale var kritikken af pgvector altid, at "det virker fint under en million vektorer, men det skalerer ikke." Det var sandt. HNSW-indeks lever udelukkende i RAM, og når dit datasæt overstiger tilgængelig hukommelse, falder ydeevnen af en klippe.

StreamingDiskANN ændrer ligningen. Ved at gemme graf-indekset på SSD i stedet for RAM håndterer pgvectorscale 50 millioner vektorer ved 471 QPS med 99 % recall. Statistical Binary Quantization (SBQ) komprimerer vektorer med minimal tab af nøjagtighed; recall falder fra 98,6 % til 96,5 %, selv med aggressiv kompression.

Den praktiske effekt: Et team, der kører en RAG-pipeline på Postgres, behøver ikke længere at planlægge en migration til en dedikeret vektordatabase, "når tingene bliver seriøse." For mange workloads er pgvector + pgvectorscale det seriøse valg.

Det sagt er pgvectorscale ikke en tryllestav. Det er en TigerData (tidligere Timescale) udvidelse, så du har brug for enten deres Docker-image eller en udbyder, der bundter det. En release i 2026 tilføjede label-baseret filtreret vektorsøgning til StreamingDiskANN, inspireret af Microsofts Filtered DiskANN-forskning, hvilket indsnævrer Qdrants langvarige føring inden for filtrerede queries. Men hvis du har brug for multi-tenant isolering eller native sparse-vektor understøttelse, har Qdrant stadig fordelen.

Hvordan Techsy griber valg af vektordatabase an

Når vi bygger RAG-pipelines for kunder, ser vores evalueringsproces sådan ud:

1. Audit af den eksisterende stack. Hvis teamet allerede kører Postgres, er pgvector det default udgangspunkt. Ingen grund til at tilføje infrastrukturel kompleksitet, medmindre der er en klar årsag.
2. Profilering af query-mønstre. Tung metadata-filtrering med high-cardinality felter? Det trækker i retning af Qdrant. Simpel semantisk søgning? pgvector eller Chroma er fint.
3. Estimering af skaleringstrajektorie. Under 5 millioner vektorer og bliver der? Enhver mulighed virker. Planlægger du 50 millioner+? pgvectorscale eller Qdrant, afhængigt af trin 2.
4. Tjek teamets ops-kapacitet. En startup med to personer bør ikke administrere et Qdrant-cluster. En managed Postgres-udbyder med pgvector er normalt det rigtige valg.

Vi har bygget produktions-RAG-systemer med alle tre. Det ærlige svar er, at valget af database betyder mindre end din chunking-strategi, din embedding-model og designet af din retrieval-pipeline. Hvis du bruger mere tid på at debattere Qdrant vs pgvector end på at teste forskellige chunk-størrelser, optimerer du det forkerte.

Har du brug for hjælp til at designe en RAG-pipeline? Valg af vector-store og design af retrieval er en del af vores AI-integrationsservice. Tag kontakt, så hjælper vi dig med at vælge det rette fundament og bygge laget omkring det.

Ofte stillede spørgsmål

Er pgvector godt nok til produktions-RAG?

Ja, især med pgvectorscale. StreamingDiskANN-indekset håndterer 50 millioner+ vektorer med 99 % recall ved throughput-niveauer, der slår dedikerede vektordatabaser i benchmarks. Hvis du allerede kører Postgres, er der sjældent en grund til at tilføje en separat vektordatabase til RAG.

Kan Chroma skalere til millioner af vektorer?

Chroma kan håndtere et par millioner vektorer på en enkelt node med nok RAM, men det har ingen indbygget horisontal skalering. For datasæt ud over, hvad en enkelt maskine kan holde, skal du migrere til Qdrant, pgvector eller en managed service.

Understøtter Qdrant hybrid søgning med keywords?

Ja. Qdrant understøtter både dense og sparse vektorer i samme collection. Du kan køre hybrid queries, der kombinerer semantisk lighed (dense) med keyword-matching (sparse) og kontrollere vægtningen mellem dem.

Hvor meget RAM har jeg brug for til hver database?

Det afhænger af antal vektorer og dimensioner. Som en grov tommelfingerregel: 1 million vektorer med 1536 dimensioner tager omkring 6 GB i Qdrant eller pgvector med HNSW. Chroma bruger lidt mere på grund af Python-overhead. pgvectorscales DiskANN-indeks reducerer RAM-behovet dramatisk ved at gemme indekset på SSD.

Kan jeg migrere mellem disse databaser senere?

Ja. Alle tre arbejder med standard float arrays, så vektorer er portable. Du skal genoprette indeks og tilpasse dit query-layer, men det er en datamigration, ikke en omskrivning. De fleste migrationsværktøjer som Qdrants officielle migrationsværktøj forenkler dette.

Hvilken fungerer bedst med LangChain og LlamaIndex?

Alle tre har officielle integrationer med LangChain og LlamaIndex. Chroma er ofte standarden i tutorials, hvilket gør det mest smertefrit at komme i gang. Qdrant- og pgvector-integrationerne er lige så modne til produktionsbrug. Tjek vores guide om de bedste RAG-værktøjer for et bredere kig på økosystemet.

Bør jeg bruge pgvector eller pgvectorscale?

Brug begge. pgvector leverer den centrale vector-type og HNSW-indekset. pgvectorscale tilføjer StreamingDiskANN ovenpå for bedre ydeevne i skala. De er komplementære udvidelser, ikke alternativer.

Er Qdrant gratis at selvhoste?

Helt gratis under Apache 2.0-licensen. Qdrant Cloud er den betalte managed mulighed, der starter med et gratis 1 GB-tier. Til selvhosting betaler du kun for compute-infrastrukturen.

Hvad med Milvus eller Weaviate i stedet?

Begge er solide alternativer. Milvus er stærkere ved meget stor skala (milliarder+ vektorer) med GPU-acceleration. Weaviate har en fin indbygget vektoriseringspipeline. Men til selvhostet RAG under 100 millioner vektorer dækker Qdrant, Chroma og pgvector langt de fleste use cases med mindre operationel kompleksitet.

Kan pgvector håndtere samtidige RAG-queries i produktion?

Ja. PostgreSQL er designet til samtidige workloads. pgvector arver connection pooling (PgBouncer), read-replikas og MVCC concurrency control. Til high-throughput RAG skal du parre pgvector med en connection pooler og tune shared_buffers og effective_cache_size.

Endelig konklusion

Samlet set: For de fleste selvhostede RAG-pipelines er pgvector + pgvectorscale det pragmatiske valg. Det er hurtigt nok, det skalerer til titusindvis af millioner af vektorer, og det holder din stack simpel. Du kender allerede SQL. Dit team administrerer allerede Postgres. Én service mindre betyder én ting mindre, der kan gå i stykker kl. 2 om natten.

Hvis du har brug for avanceret filtreret søgning, multi-tenancy, eller bygger et produkt, hvor vektorsøgning er kerneproduktet (ikke en støttende kapacitet), er Qdrant den rigtige investering. Det er den mest funktionsrige open source-vektordatabase af en grund.

Chroma fortjener sin plads som prototyping-værktøjet. Brug det til at validere din RAG-tilgang, teste forskellige chunking-strategier og iterere på retrieval-kvaliteten. Når du er klar til produktion, migrerer du til den af de to andre, der passer til din stack.

Det bedste råd? Stop med at debattere og begynd at bygge. Vælg pgvector, hvis du har Postgres, Qdrant hvis du ikke har, og få din RAG-pipeline til at virke. Du kan altid skifte vector store senere; embedding-modellen, chunk-strategien og retrieval-logikken betyder langt mere.

Kilder

• 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