Vectordatabases vergeleken: Qdrant vs Weaviate vs pgvector vs Milvus

Wanneer een bedrijf besluit RAG (Retrieval-Augmented Generation) in te zetten op bedrijfsdocumentatie, luidt de eerste technische vraag: waar slaan we de vectoren op? Het antwoord is niet neutraal — de keuze beïnvloedt de latency van antwoorden, de maandelijkse infrastructuurkosten, de onderhoudsbelasting en wat er wel en niet mogelijk is als het datavolume verdubbelt. In de praktijk zien we dat teams het vaakst grijpen naar een van deze vier oplossingen: pgvector, Qdrant, Weaviate en Milvus. Elk heeft een eigen scope, eigen sterke punten en een eigen context waarin het zinvol is.

Dit artikel is geen benchmarkwedstrijd (publiek beschikbare benchmarks zijn per definitie afhankelijk van hardware, dimensionaliteit en belastingspatroon). Het is een beslissingsraamwerk — hoe u kiest op basis van wat uw bedrijf daadwerkelijk nodig heeft.

Wat alle vier gemeen hebben

Alle vier oplossingen ondersteunen approximate nearest neighbor (ANN)-zoekopdrachten met een HNSW-index, filtering op metadata en integratie met gangbare embedding-modellen. Alle vier zijn open-source (Apache 2.0 of gelijkwaardig) met de mogelijkheid tot self-hosting of een managed cloud-variant. Een gangbare embeddingdimensie van 1 024 of 1 536 is voor geen van hen een probleem.

Het verschil begint wanneer u stuit op schaal, consistentievereisten, bestaande infrastructuur of de behoefte aan hybride zoekopdrachten (vector + keyword). Daar splitsen de vier paden zich.

pgvector — als u al Postgres hebt

pgvector is een extensie voor PostgreSQL. Het bestaat niet als zelfstandige database — het draait binnen uw bestaande PG-instantie. Dat is tegelijkertijd zijn sterkste argument én zijn voornaamste beperking.

Wanneer dit zinvol is:

Als uw bedrijf PostgreSQL gebruikt en het aantal vectoren de orde van grootte van tientallen miljoenen niet overschrijdt, is pgvector een legitieme productiekeuze. Het voordeel is fundamenteel: vectoren, gestructureerde data en metadata leven in één database, onder één transactie, met één back-upproces. Geen synchronisatie tussen twee systemen, geen extra infrastructuur nodig.

De versie van pgvector uit begin 2026 voegde ondersteuning voor sparse vectoren toe en verbeterde de prestaties van de IVFFlat-index aanzienlijk. Met een HNSW-index en de juiste configuratie verwerkt de database op een standaardserver 5 000 tot 15 000 QPS bij een collectie van circa 10 miljoen vectoren met dimensie 1 024. Voor de grote meerderheid van B2B RAG-deployments op interne documentatie is dat voldoende.

Waar de limieten liggen:

Bij collecties boven de 50 miljoen vectoren stuit PG op de eigenschappen van zijn architectuur — een rowstore geoptimaliseerd voor transactieworkloads, niet voor pure ANN-doorvoer. De prestaties dalen en schalen vereist ofwel sharding ofwel overstap naar een andere oplossing. Een verdere beperking: pgvector heeft geen native hybride zoekopdracht — het combineren van vector- en keyword-zoeken vereist handmatige pipelinebouw, bijvoorbeeld via tsvector en handmatige RRF (Reciprocal Rank Fusion).

Typisch projectprofiel: interne knowledge base of klantenservice, collectie van 1–5 miljoen vectoren, een team dat bestaande Postgres beheert en voorkeur heeft om de infrastructuur niet uit te breiden.

Qdrant — prestaties en single-node self-hosting

Qdrant is een database die van de grond op gebouwd is voor vectorzoekopdrachten. Geschreven in Rust, met nadruk op prestaties en eenvoudige self-hosted deployment — een binary of Docker-container, geen externe afhankelijkheden.

De sleuteleigenschap die Qdrant in 2026 onderscheidt: native ondersteuning voor ColBERT-style multi-vector (late interaction), dat wil zeggen de mogelijkheid om meerdere vectoren per document op te slaan en te zoeken via hun onderlinge interactie. Dit maakt state-of-the-art retrieval mogelijk zonder externe reranker-server — Qdrant verwerkt de late interaction direct in de index. Voor projecten waar nauwkeurigheid telt en u geen aparte reranker-service wilt bouwen, is dit een aanzienlijk voordeel.

Prestatiekarakteristiek: bij 10 miljoen vectoren, 1 024 dimensies, een belasting van circa 1 000 QPS beweegt de P99-latency zich rond de 12 ms. Schaalt goed naar honderden miljoenen vectoren op een single node met voldoende RAM, of via Qdrant Cloud managed service voor grotere installaties.

Hybride zoekopdracht: Qdrant ondersteunt sparse vectoren (BM25-stijl) als eersteklas functie — dense vector + sparse vector worden dus in één doorgang doorzocht, zonder handmatig samenvoegen van resultaten. Voor het typische enterprise RAG-scenario (technische documentatie, productcatalogi, servicehandleidingen) is dit ideaal — exacte trefwoorden (onderdeelnummers, codes, specifieke termen) worden gevangen door de sparse tak, semantiek door de dense tak.

Wanneer dit zinvol is:

Het team wil een self-hosted oplossing, voorspelbare latency, native hybride zoekopdracht en wil geen gedistribueerd cluster beheren. De collectie kan variëren van miljoenen tot honderden miljoenen vectoren. Beheerders met één persoon op infra geven de voorkeur aan eenvoudige deployment.

Waar de limieten liggen:

Bij echt grote collecties (miljarden vectoren) is de native distributie beperkter dan bij Milvus. Het ecosysteem van integratieconnectoren is kleiner dan bij Weaviate.

Weaviate — modulaire hybride zoekopdracht

Weaviate heeft een andere filosofie dan Qdrant: elke functionaliteit is een module — embedding-generatie, keyword-indexering, reranking, multimodale input. Dat gaat ten koste van eenvoud, maar geeft grote flexibiliteit zonder custom code.

Sleuteleigenschap: native hybride zoekopdracht (BM25 + dense vector + metadata-filter) als eersteklas functie in de query-API. De BM25-index en de vector-index zijn geïntegreerd in één query-planner met automatische RRF-fusion. Weaviate onderscheidt zich ook door een rijke GraphQL query-API, die teams waarderen die complexe filtering nodig hebben (multi-tenant, toegangsrechten, hiërarchische metadata).

Prestaties: indicatief 25 000 tot 50 000 QPS bij 10 miljoen vectoren, P99-latency circa 16 ms. De kosten van de cloud-variant (Weaviate Cloud) zijn hoger dan Qdrant, maar het team krijgt managed reranking, monitoring en SLA.

Wanneer dit zinvol is:

Multi-tenant deployment (meerdere klanten/afdelingen in één instantie met geïsoleerde data), behoefte aan geavanceerde filtering, een team dat een managed service met een rijker ecosysteem waardeert. Ook een goede keuze voor projecten met multimodale content, waarbij de Weaviate-module voor image embedding custom code bespaart.

Waar de limieten liggen:

De modulaire architectuur voegt operationele complexiteit toe — meer configuraties, meer faalmogelijkheden. Voor een eenvoudige RAG use-case is Weaviate overengineered. De schema-first aanpak (typen definiëren vóór indexering) kan prototyping vertragen.

Milvus — extreme schaal

Milvus is distributed-first vanaf de eerste regel code. Het draait op Kubernetes, met etcd voor coördinatie, S3-compatibele opslag voor persistentie en afzonderlijke componenten voor ingestie, indexering en queries. Deze architectuur is overhead voor kleine projecten — en een voordeel voor grote.

Bij collecties van miljarden vectoren bereikt Milvus een doorvoer van 100 000+ QPS met horizontale schaling. GPU-versneld ANN-zoeken verlaagt de latency verder bij grote indexen. De managed versie — Zilliz Cloud — neemt de operationele last over.

Wanneer dit zinvol is:

Collectie van meer dan 100 miljoen vectoren, high-throughput workload (e-commerce-personalisatie, aanbevelingssystemen, vectorzoeken in een catalogus van miljarden items), een team met DevOps-capaciteit om een Kubernetes-stack te beheren.

Waar de limieten liggen:

Voor gewone enterprise RAG met miljoenen vectoren is Milvus onnodige overhead. Een minimale productie-installatie vereist meerdere componenten — etcd-cluster, MinIO/S3, query nodes, data nodes. Voor een eenmansteam is dat te veel infrastructuur om te onderhouden. Hybride zoeken bestaat, maar is minder vloeiend dan bij Qdrant of Weaviate.

Beslissingsraamwerk: drie vragen vóór de keuze

In plaats van vergelijken in een tabel (waarbij elk veld context vereist) raden we aan drie vragen in volgorde te beantwoorden:

1. Hoe groot is de collectie nu en over 2 jaar?

• Tot 5 miljoen vectoren én bestaande Postgres → probeer pgvector eerst. U vermijdt nieuwe infrastructuur.
• 5 miljoen tot honderden miljoenen → Qdrant of Weaviate volgens de volgende criteria.
• Miljarden vectoren of 100 000+ QPS → Milvus / Zilliz Cloud.

2. Hoeveel mensen beheren de infrastructuur?

• Één ontwikkelaar of een klein team → Qdrant (eenvoudige self-hosting, binary/Docker, minimale afhankelijkheden).
• Een team met DevOps-capaciteit dat de voorkeur geeft aan een managed service → Weaviate Cloud of Zilliz Cloud.
• Een Kubernetes-native team met ervaring in gedistribueerde systemen → Milvus.

3. Wat is de structuur van de queries?

• Puur semantisch zoeken → elke van deze databases volstaat.
• Hybride (keyword-precisie + semantiek) → Qdrant (sparse + dense native) of Weaviate (BM25 + dense native). Bij gebruik van pgvector moet hybride handmatig worden samengesteld.
• Multi-tenant met geïsoleerde data, complexe filtering → Weaviate heeft de meest geavanceerde query-planning.
• ColBERT / multi-vector late interaction → Qdrant is in 2026 als enige van deze vier native.

Prestatiecijfers in context

Publiek beschikbare benchmarks (zoals ann-benchmarks.com en andere publieke vergelijkingen) tonen indicatief:

Bij een belasting van circa 1 000 QPS op een collectie van 10 miljoen vectoren met 1 024 dimensies:

• pgvector: maximaal 5 000–15 000 QPS, P99-latency variabel afhankelijk van hardware
• Qdrant: 30 000–80 000 QPS, P99 circa 12 ms
• Weaviate: 25 000–50 000 QPS, P99 circa 16 ms
• Milvus: 100 000+ QPS met horizontale schaling, P99 circa 18 ms (distributed setup)

Deze cijfers zijn sterk indicatief — werkelijke resultaten hangen af van de dimensionaliteit van de vectoren, de indexeringsstrategie (HNSW-parameters), de hardware (geheugen, CPU/GPU), het belastingspatroon en of het gaat om een single-tenant of multi-tenant workload. Een benchmark uit een ander project is slechts een startpunt voor uw eigen meting.

Maandelijkse kosten voor cloud managed-varianten bedragen bij een typische enterprise RAG-workload (10 miljoen vectoren, ~1 000 QPS) ruwweg enkele duizenden euro's — met aanzienlijke verschillen afhankelijk van provider en regio. Self-hosting op eigen servers verlaagt de variabele kosten, maar voegt vaste beheerkosten toe.

Waar pgvector positief verrast

Een van de meest voorkomende mythes bij SK/EU-bedrijven: "pgvector is alleen een tussenoplossing voor PoC". In de praktijk is dat niet zo. Bij klanten uit de productie en logistiek zien we RAG-deployments op 2–3 miljoen vectoren die in productie draaien op pgvector zonder problemen, waarbij de enige motivatie een bestaand PostgreSQL-cluster was en een team zonder bandbreedte voor nieuwe infrastructuur.

Cruciaal voor goede pgvector-prestaties in productie: HNSW-index (niet IVFFlat), correcte configuratie van maintenance_work_mem voor indexbouw, en partitionering als de collectie groeit. Met deze instellingen verwerkt pgvector de meeste enterprise interne RAG-scenario's zonder overstap.

Waar pgvector daadwerkelijk tekortschiet: geavanceerde hybride zoekopdrachten, multi-vector / ColBERT-retrieval, en collecties van tientallen miljoenen waarbij de prestaties van de retrieval-laag kritisch zijn voor UX (latency onder 20 ms).

Integratie met RAG-frameworks

Alle vier databases hebben eersteklas integratie in zowel LlamaIndex als LangChain. LlamaIndex beschikt over native QdrantVectorStore, WeaviateVectorStore, PGVectorStore en MilvusVectorStore met een consistent interface — migratie tussen databases is een refactor op het niveau van één configuratieregel (niet van de volledige pipeline).

Voor de keuze van het framework en de evaluatie van de RAG-pipelinekwaliteit verwijzen we naar RAG-pipeline — 3 instellingen die de kwaliteit bepalen — daar worden chunkingstrategieën, embedding-upgrades en reranking uitgebreid besproken, die onafhankelijk zijn van de keuze voor de vectordatabase.

Het embedding-model is een afzonderlijke beslissing — voor de selectie ervan, zie Hoe kies je een embedding-model en voor hybride zoekopdrachten met BM25 en vectoren Hybride zoekopdracht (BM25 + vectoren + reranking).

Veelgestelde vragen

Kan ik beginnen met pgvector en later migreren naar Qdrant?

Ja, en dat is een gangbaar patroon. De abstractielaag van de vector store in LlamaIndex is dun genoeg — migratie vereist het heringesten van vectoren (documenten opnieuw indexeren) en het aanpassen van de store-configuratie. De pipeline-logica, chunking en het embedding-model blijven ongewijzigd. Zolang u de originele teksten en metadata opslaat in een relationele database, is het heringesten doorgaans een script, geen maandenwerk.

Is Qdrant echt sneller dan Weaviate voor mijn workload?

Dat hangt af van het belastingspatroon. Qdrant toont een voordeel in single-tenant scenario's met uniforme queries. Weaviate kan comparatief beter presteren bij complexe multi-tenant filtering, waarbij zijn query-planner de doorsnede van vector- en keyword-filter optimaliseert. Wij raden aan een eigen benchmark uit te voeren op een representatief sample van uw data — 1 uur meten op uw eigen corpus is waardevoller dan welke publieke benchmark dan ook.

Hebben we Milvus nodig als we 50 miljoen vectoren hebben?

Waarschijnlijk niet. Qdrant en Weaviate verwerken honderden miljoenen vectoren op een goed geconfigureerde single-node server. Milvus is gerechtvaardigd bij collecties van miljarden of bij de behoefte aan 100 000+ QPS, waar de gedistribueerde architectuur daadwerkelijk besparing oplevert. Voor 50 miljoen vectoren is Milvus eerder overhead dan oplossing.

Beïnvloedt de keuze van vectordatabase de antwoordkwaliteit van RAG?

Direct weinig — de antwoordkwaliteit hangt primair af van de kwaliteit van chunking, het embedding-model en de reranker, niet van welke database de vectoren opslaat. Indirect wel: als de vectordatabase een hoge latency of lage recall heeft bij gefilterd zoeken, komen er kwalitatief mindere contextfragmenten in het generatieve model terecht. De databasekeuze beïnvloedt vooral prestaties, kosten en operationele belasting — niet de logica van de retrieval-pipeline zelf.

Werkt pgvector ook voor Nederlandse tekst?

Ja — een vectordatabase is taalonafhankelijk. Hij slaat vectoren op en zoekt erin ongeacht de taal. Taaleigenschappen zijn de verantwoordelijkheid van het embedding-model, niet van de database. Voor Nederlands (en andere EU-talen) raden wij multilinguale modellen aan zoals BGE-M3 of Qwen3-Embedding — meer daarover in het artikel Hoe kies je een embedding-model.

*MP Industrial Solutions helpt bedrijven bij het ontwerpen en implementeren van RAG-infrastructuur die is afgestemd op de werkelijke workload — van de beoordeling of pgvector volstaat tot en met productie-deployment van Qdrant of Weaviate op on-premises servers. Als u een deployment overweegt of prestatiegproblemen ondervindt met een bestaande vectorlaag, plannen we graag een vrijblijvend kennismakingsgesprek.*