Qdrant vs Chroma vs pgvector: Velge riktig vektordatabase for selvhosted RAG

Qdrant vs Chroma vs pgvector: Velge riktig vektordatabase for selvhosted RAG

Beslutningen Qdrant vs Chroma vs pgvector handler om en treveisvurdering: formålsbygget hastighet, prototypenkelhet, eller å bli innenfor Postgres-økosystemet. Hver tilnærming fungerer, spørsmålet er hvilken avveining som passer din RAG-pipeline.

Rask oppsummering: Hvilken vektordatabase bør du velge?

Velg Qdrant hvis du trenger produksjonskvalitets vektorsøk med avansert filtrering, multi-tenancy, og ikke har noe imot å kjøre en separat tjeneste.

Velg Chroma hvis du prototyper, ønsker nullkonfigurasjon lokal utvikling, eller trenger å gå fra idé til fungerende RAG på under en time.

Velg pgvector (+ pgvectorscale) hvis du allerede kjører PostgreSQL og ønsker vektorsøk uten å legge til infrastruktur, spesielt nå som pgvectorscales StreamingDiskANN-indeks har tettet ytelseshullet.

Hvis du bygger en RAG-applikasjon fra bunnen hjelper resten av dette innlegget deg å velge riktig fundament.

Ytelse: Hvor rask er hver database?

Ytelse spiller en rolle når du går utover noen tusen dokumenter. Her er der disse tre avviker betydelig.

Qdrant

Qdrant er bygget fra bunnen for vektorsøk. Rust-implementeringen og den tilpassede HNSW-indeksen leverer konsekvent lav latens, referanser viser spørrelatens rundt 94 ms selv under samtidig belastning. Den støtter skalær, binær og produktkvantisering for å komprimere vektorer og øke søkehastigheten mens recall holdes over 95%.

Der Qdrant virkelig skinner er filtrert søk. I motsetning til databaser som finner nærmeste naboer først og deretter filtrerer, respekterer Qdrants filtrerbare HNSW metadatbegrensninger under graftraversering. Det betyr at du ikke mister recall når du kombinerer vektorsøk med filtre som category = "technical" eller date > 2025-01-01.

Chroma

Chromas versjon 1.0 skrev om kjernen i Rust, og leverte 3-5x raskere skriving og spørringer sammenlignet med den opprinnelige Python-implementeringen. En oppfølgingsoppdatering i august 2025 la til base64-vektorkoding for ytterligere 70% gjennomstrømmingsøkning.

For datasett under en million vektorer er Chroma genuint rask. Den kjører innebygd i Python-prosessen din uten nettverksoverhead, noe som gjør lokal iterasjon rask. Men det er en enkelt-knutepunktsdatabase, ingen innebygd sharding eller replikering.

pgvector + pgvectorscale

Dette er outsiderne. Vanlig pgvector med HNSW er 5 250 ganger raskere enn en sekvensiell skanning, og pgvector 0.8.0 la til iterativ indeksskanning for å løse overfiltrerings-problemet som plaget tidligere versjoner.

Men den virkelige historien er pgvectorscale. Timescales utvidelse legger til StreamingDiskANN-indeksen, inspirert av Microsofts DiskANN-forskning, som lagrer indeksen på disk i stedet for RAM. På en referanse med 50 millioner Cohere-embeddings (768 dimensjoner) oppnådde pgvectorscale 471 QPS ved 99% recall. Det er 11,4x høyere gjennomstrømning enn Qdrants 41 QPS på samme recall-nivå, og 28x lavere p95-latens enn Pinecones lagringsoptimerte indeks.

Haken? Disse referansene brukte en kraftig EC2-instans. Resultatene dine avhenger av maskinvare. Men trenden er klar: PostgreSQL er ikke lenger "godt-nok"-alternativet for vektorsøk, det er genuint konkurranse dyktig.

Dom: pgvector + pgvectorscale vinner på rå referansetall. Qdrant vinner på filtrert søkeytelse. Chroma er raskt nok for prototyper men er ikke bygget for skala.

Oppsett og utvikleropplevelse

Hvor raskt kan du gå fra null til vektorer?

Qdrant: Docker og i gang

Qdrant trenger sin egen container:

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

Deretter setter du inn vektorer via REST-API-et eller ett av de offisielle SDK-ene (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 dashbord på localhost:6333/dashboard er et fint innslag, du kan bla gjennom samlinger, kjøre spørringer og inspisere payloads visuelt. Veien fra utvikling til produksjon er ren: det lokale Docker-oppsettet ditt fungerer identisk på en produksjonsserver eller Qdrant Cloud.

Chroma: pip install og ferdig

Chroma vinner enkelhetsracet med bred margin:

import chromadb

client = chromadb.Client()  # I minne, nullkonfigurasjon
collection = client.create_collection("documents")
collection.add(
    documents=["Ditt RAG-dokument her"],
    ids=["doc1"]
)

Ingen Docker. Ingen server. Den håndterer til og med embedding-generering automatisk hvis du ikke oppgir vektorer. For en RAG-prototyp kan du gå fra pip install chromadb til fungerende søk på under 10 linjer.

Når du er klar for persistens, bytt til chromadb.PersistentClient(path="./chroma_data"). For flerprosesstilgang eller nettverkstilgang har Chroma en servermodus, men da begynner du å miste enkelhetsfordelen.

pgvector: SQL hele veien

Hvis Postgres allerede er i stacket ditt, er pgvector én linje:

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. Embeddingene dine lever ved siden av applikasjonsdataene dine i den samme transaksjonen. Ingen synkroniseringspipeline, ingen separate legitimasjoner, ingen ekstra tjeneste å overvåke. Hvis du allerede kjører PostgreSQL i produksjon er dette veien med minst motstand.

Å legge til pgvectorscale på toppen er enkelt hvis du bruker Timescales Docker-image eller en administrert Postgres-leverandør som støtter det:

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

Ulempen? SQL er ikke like ergonomisk som Qdrants payload-filtreringsDSL eller Chromas Pythonistiske API. Og du må administrere din egen embedding-pipeline, pgvector genererer ikke embeddings for deg.

Dom: Chroma vinner for raskeste prototype. pgvector vinner hvis Postgres allerede er i stacket. Qdrant har den beste balansen mellom utvikleropplevelse og produksjonsmodenhet.

Skalering og produksjonsmodenhet

Prototyping er én ting. Å kjøre en RAG-pipeline som håndterer millioner av vektorer med konsekvent latens er noe annet.

Qdrant: Bygget for horisontal skalering

Qdrant støtter horisontal sharding rett ut av boksen. Du kan distribuere samlinger på tvers av flere knutepunkter, med konfigurerbare replikeringsfaktorer for høy tilgjengelighet. Dets 2026-veikart inkluderer lese-skriv-segregering og blokklagringsintegrasjon for enda bedre skalering.

Multi-tenancy er en førsteklasses funksjon. Du kan partisjonere data etter leietaker ved hjelp av payload-basert filtrering uten å opprette separate samlinger, noe som holder ressursbruken effektiv. For AI-agentminnessystemer som håndterer flere brukere er dette en meningsfull fordel.

Den operative historien er solid: innebygde sikkerhetskopier, metrikkendepunkter for Prometheus og WAL-basert krasjgjenoppretting. Qdrant er designet for å være selvhosted i produksjon.

Chroma: Enkelt-knutepunktsgrense

Chroma er ærlig om sine begrensninger. Det er en enkelt-knutepunktsdatabase fokusert på enkelhet og lokal utvikling. Ingen innebygd sharding, ingen replikering og ingen clustering.

Chroma Cloud ble allment tilgjengelig tidlig i 2026 som et serverløst, distribuert administrert alternativ, men den selvhostede historien er i hovedsak "én server, én Chroma-instans." Hvis datasettet ditt passer på en enkelt maskin (opp til noen millioner vektorer avhengig av dimensjonalitet), er det greit. Utover det vil du støte på en vegg.

pgvector: Skalerer med Postgres

pgvector arver PostgreSQLs velprøvde skaleringshistorie. Du får lesereplika, tilkoblingspooling via PgBouncer og logisk replikering. Administrerte leverandører som Neon og lignende serverløse Postgres-plattformer gjør vertikal skalering nesten mühesam.

pgvectorscales StreamingDiskANN-indeks er nøkkelen for skalering. Fordi den lagrer grafindeksen på SSD-er i stedet for RAM, kan du håndtere datasett som ellers ville kreve dyre høyminne-instanser. Ved 50 millioner vektorer er den allerede konkurransedyktig med dedikerte vektordatabaser.

Begrensningen er horisontal sharding. PostgreSQL sharder ikke nativt slik Qdrant gjør. Løsninger som Citus finnes, men legger til kompleksitet. For de fleste selvhostede RAG-arbeidsmengder under 100M vektorer er vertikal skalering med pgvectorscale tilstrekkelig.

Dom: Qdrant vinner for horisontal skalering og multi-tenancy. pgvector vinner for å utnytte eksisterende Postgres-infrastruktur. Chroma er ikke designet for produksjons-skala.

Kostnad for selvhosting

Alle tre er åpen kildekode og gratis å kjøre. Den virkelige kostnaden er infrastruktur og ingeniørtid.

pgvector har en strukturell kostnadsfordel: hvis du allerede betaler for Postgres, er det i bunn og grunn gratis å legge til vektorsøk til du trenger dedikerte ressurser. Ingen ekstra container, ingen ekstra overvåking, ingen ekstra sikkerhetskopieringsstrategi.

Qdrants ressursbruk er effektiv for funksjonssettet, men det er en separat tjeneste, du må ta hensyn til den operative overheaden ved å kjøre og overvåke et nytt stykke infrastruktur.

Chroma er billigst i prototypfasen (null infrastruktur) men blir den dyreste veien hvis du prøver å skalere den utover hva en enkelt node kan håndtere.

For distribusjon på skyplattformer har Qdrant og pgvector begge enkle Docker-baserte distribusjoner. Chroma fungerer også, men du mister den innebygde enkelheten som er dens viktigste salgsargument.

Dom: pgvector vinner på total eierkostnad (TCO). Det eliminerer en hel tjeneste fra stacket. Qdrant er rimelig priset for det det tilbyr. Chromas kostnadshistorie fungerer bare under prototyping.

Filtrering og hybridsøk

RAG handler ikke bare om å "finne nærmeste vektor." Du trenger å kombinere likhetssøk med metadatafiltre, datoområder, tilgangskontroller og noen ganger nøkkelordsmatching.

Qdrant: Filtreringskungen

Qdrants payload-filtrering skjer under HNSW-traverseringen, ikke etterpå. Det er en kritisk distinksjon. Etterfiltrering kan redusere resultatantallet under hva du spurte om; forfiltrering garanterer at du får k resultater som matcher begrensningene dine.

Filtreringsspråket er 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øtter også nativt hybridsøk med både tette og glisne vektorer i samme spørring, noe som er nyttig for å kombinere semantisk forståelse med nøkkelordspresisjon.

Chroma: Grunnleggende men brukbart

Chroma støtter metadatafiltrering med where-setninger:

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

Det fungerer for enkle tilfeller, men filtrering skjer etter vektorsøket. Med restriktive filtre og små datasett kan du få færre resultater enn forventet. Det er ingen støtte for glisne vektorer eller innebygd hybridsøk.

pgvector: SQL er superkraften din

pgvector arver den fulle kraften til SQL for 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 siste linjen kombinerer vektorlikhet med PostgreSQLs innebygde fulltekstsøk i en enkelt spørring. Ingen ekstern søkemotor trengs. Du kan gjøre joins mot brukertabellen din for tilgangskontroll, aggregere resultater, bruke CTE-er, alt SQL kan gjøre.

pgvector 0.8.0s iterative skanning hjelper også. Hvis den første HNSW-skanningen ikke returnerer nok filtrerte resultater, fortsetter den automatisk å søke i stedet for å returnere et delvis sett.

Dom: Qdrant vinner for kompleks metadatafiltrering i stor skala. pgvector vinner for hybridsøkfleksibilitet (SQL + fulltekst + vektor i én spørring). Chromas filtrering er tilstrekkelig bare for prototyper.

Når du skal bruke hver: Beslutningsrammeverk

Her er beslutningstreversjonen: Bruker appen din allerede Postgres? Hvis ja, start med pgvector, du kan alltid migrere senere hvis du vokser fra det. Hvis nei, prototyper du eller bygger du for produksjon? Prototype går mot Chroma. Produksjon går mot Qdrant.

Tilnærmingen "start enkelt, migrer senere" er gyldig fordi alle tre støtter standard embeddingformater. Å flytte vektorer mellom dem er en datamigrering, ikke en arkitekturomskriving.

pgvectorscale-faktoren: Hvorfor Postgres tar igjen

Verdt å dvele ved her fordi det endrer beregningen for mange team.

Før pgvectorscale var kritikken mot pgvector alltid "det fungerer fint under en million vektorer, men det skalerer ikke." Det stemte. HNSW-indekser lever helt i RAM, og når datasettet ditt overstiger tilgjengelig minne, faller ytelsen dramatisk.

StreamingDiskANN endrer ligningen. Ved å lagre grafindeksen på SSD i stedet for RAM håndterer pgvectorscale 50 millioner vektorer ved 471 QPS med 99% recall. Statistisk binær kvantisering (SBQ) komprimerer vektorer med minimal nøyaktighetstap, recall faller fra 98,6% til 96,5% selv med aggressiv komprimering.

Den praktiske virkningen: et team som kjører en RAG-pipeline på Postgres trenger ikke lenger planlegge en migrering til en dedikert vektordatabase "når ting blir seriøst." For mange arbeidsmengder er pgvector + pgvectorscale det seriøse alternativet.

Sagt det, er pgvectorscale ikke en sølvkule. Det er en utvidelse fra TigerData (tidligere Timescale), så du trenger enten Docker-imaget deres eller en leverandør som inkluderer det. En utgivelse i 2026 la til etikettbasert filtrert vektorsøk i StreamingDiskANN (inspirert av Microsofts Filtered DiskANN-forskning), noe som krymper Qdrants langvarige forsprang på filtrerte spørringer. Men hvis du trenger multi-tenant isolasjon eller innebygd støtte for glisne vektorer, har Qdrant fortsatt fordelen.

Hvordan Techsy nærmer seg valg av vektordatabase

Når vi bygger RAG-pipelines for kunder, ser evalueringsprosessen vår slik ut:

1. Revidere den eksisterende stacken. Hvis teamet allerede kjører Postgres, er pgvector standard utgangspunkt. Det er ingen vits å legge til infrastrukturkompleksitet uten en klar grunn.
2. Profilere spørringsmønstrene. Tung metadatafiltrering med høyt kardinalitetsfelt? Det peker mot Qdrant. Enkelt semantisk søk? pgvector eller Chroma er fint.
3. Estimere skaleringsveien. Under 5M vektorer og holder seg der? Hvilket alternativ som helst fungerer. Planlegger 50M+? pgvectorscale eller Qdrant, avhengig av trinn 2.
4. Sjekke teamets ops-kapasitet. En to-personers startup bør ikke administrere et Qdrant-kluster. En administrert Postgres-leverandør med pgvector er vanligvis det riktige valget.

Vi har bygget produksjons-RAG-systemer med alle tre. Det ærlige svaret er at databasevalget betyr mindre enn chunking-strategien din, embeddingmodellen og utformingen av hentingspipelinen. Hvis du bruker mer tid på å diskutere Qdrant vs pgvector enn å teste ulike chunk-størrelser, optimaliserer du feil ting.

Trenger du hjelp med å designe en RAG-pipeline? Valg av vektorlager og utforming av henting er en del av vår AI-integrasjonstjeneste. Kontakt oss, så hjelper vi deg å velge riktig grunnlag og bygge laget rundt det.

Vanlige spørsmål

Er pgvector godt nok for produksjons-RAG?

Ja, spesielt med pgvectorscale. StreamingDiskANN-indeksen håndterer 50M+ vektorer med 99% recall ved gjennomstrømningsnivåer som slår dedikerte vektordatabaser i referanser. Hvis du allerede kjører Postgres, er det sjelden grunn til å legge til en separat vektordatabase for RAG.

Kan Chroma skalere til millioner av vektorer?

Chroma kan håndtere et par millioner vektorer på en enkelt node med nok RAM, men har ingen innebygd horisontal skalering. For datasett utover hva en enkelt maskin kan holde, må du migrere til Qdrant, pgvector eller en administrert tjeneste.

Støtter Qdrant hybridsøk med nøkkelord?

Ja. Qdrant støtter både tette og glisne vektorer i den samme samlingen. Du kan kjøre hybridspørringer som kombinerer semantisk likhet (tett) med nøkkelordsmatching (glisent) og kontrollere vektingen mellom dem.

Hvor mye RAM trenger jeg for hver database?

Det avhenger av vektortall og dimensjoner. Som en grov veiledning: 1M vektorer ved 1 536 dimensjoner tar omtrent 6 GB i Qdrant eller pgvector med HNSW. Chroma bruker litt mer på grunn av Python-overhead. pgvectorscales DiskANN-indeks reduserer RAM-behovet dramatisk ved å lagre indeksen på SSD.

Kan jeg migrere mellom disse databasene senere?

Ja. Alle tre fungerer med standard float-arrayer, så vektorer er bærbare. Du må gjenopprette indekser og tilpasse spørringslaget, men det er en datamigrering, ikke en omskriving. De fleste migrasjonsverktøy som Qdrants offisielle migrasjonsverktøy forenkler dette.

Hvilken fungerer best med LangChain og LlamaIndex?

Alle tre har offisielle integrasjoner med LangChain og LlamaIndex. Chroma er ofte standard i opplæringsprogrammer, noe som gjør det smidigst å komme i gang med. Qdrant- og pgvector-integrasjoner er like modne for produksjonsbruk. Sjekk vår veiledning om de beste RAG-verktøyene for et bredere blikk på økosystemet.

Bør jeg bruke pgvector eller pgvectorscale?

Bruk begge. pgvector gir basis-vector-typen og HNSW-indeksen. pgvectorscale legger til StreamingDiskANN på toppen for bedre ytelse i stor skala. De er komplementære utvidelser, ikke alternativer.

Er Qdrant gratis å selvhoste?

Helt gratis under Apache 2.0-lisensen. Qdrant Cloud er det betalte administrerte alternativet, som starter med et gratis 1 GB-nivå. For selvhosting betaler du bare for beregningsinfrastrukturen.

Hva med Milvus eller Weaviate?

Begge er solide alternativer. Milvus er sterkere ved svært stor skala (milliarder+ vektorer) med GPU-akselerasjon. Weaviate har en fin innebygd vektoriseringspipeline. Men for selvhosted RAG under 100M vektorer dekker Qdrant, Chroma og pgvector det store flertallet av brukstilfeller med mindre operasjonell kompleksitet.

Kan pgvector håndtere samtidige RAG-spørringer i produksjon?

Ja. PostgreSQL er designet for samtidige arbeidsmengder. pgvector arver tilkoblingspooling (PgBouncer), lesereplika og MVCC-samtidsstyring. For høygjennomstrømnings-RAG, par pgvector med en tilkoblingspooler og juster shared_buffers og effective_cache_size.

Endelig dom

Overordnet: For de fleste selvhostede RAG-pipelines er pgvector + pgvectorscale det pragmatiske valget. Det er raskt nok, skalerer til titalls millioner vektorer, og holder stacket enkelt. Du kan SQL allerede. Teamet ditt administrerer Postgres allerede. Én tjeneste mindre betyr én ting mindre som kan gå i stykker klokken 2 om natten.

Hvis du trenger avansert filtrert søk, multi-tenancy, eller bygger et produkt der vektorsøk er kjernefunksjonen (ikke en støttende evne), er Qdrant den rette investeringen. Det er den mest fullstendige open-source-vektordatabasen av en grunn.

Chroma fortjener sin plass som prototypingverktøy. Bruk det til å validere RAG-tilnærmingen din, teste ulike chunking-strategier og iterere på hentingskvalitet. Når du er klar for produksjon, migrer til hvilken av de to andre som passer stacket ditt.

Det beste rådet? Slutt å diskutere og begynn å bygge. Velg pgvector hvis du har Postgres, Qdrant hvis du ikke har det, og få RAG-pipelinen din til å fungere. Du kan alltid bytte vektorlager senere, embeddingmodellen, chunk-strategien og hentingslogikken betyr mye mer.

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