Vectordatabases voor RAG vergeleken (2026)

Als je een retrieval-augmented generation (RAG)-systeem bouwt, bepaalt de vectordatabase die je kiest stilletjes de kosten, de latency en hoe lastig het is om alles in productie draaiend te houden. Een vectordatabase voor RAG slaat de numerieke embeddings van je documenten op en vindt in milliseconden de beste match bij de vraag van een gebruiker, zodat het taalmodel antwoordt op basis van jóuw data in plaats van te gokken. Kies je goed, dan verdwijnt de database naar de achtergrond; kies je verkeerd, dan ben je maanden bezig met recall, beheerlast of een rekening die sneller groeit dan je gebruik. Dit is een leveranciersonafhankelijke vergelijking van de vier opties die de meeste teams in 2026 echt op hun shortlist zetten: pgvector, Qdrant, Weaviate en Pinecone.

Wij bouwen deze systemen dagelijks, dus dit is geschreven vanuit de engineeringstoel, niet de marketingstoel. Er is geen absolute winnaar, en wie iets anders beweert, verkoopt je iets. Er is alleen de juiste keuze voor jouw datavolume, jouw team, jouw latency-budget en jouw regelgeving — en in Nederland en de bredere EU weegt dat laatste zwaarder dan de meeste vergelijkingen toegeven.

Wat een vectordatabase doet in een RAG-systeem

RAG werkt door je documenten om te zetten in embeddings — lange reeksen getallen die betekenis vastleggen — en die zo op te slaan dat je bij een vraag de passages kunt vinden die het meest lijken op de vraag van de gebruiker, om die vervolgens als context aan het model te geven. De vectordatabase maakt die stap ("vind de meest gelijkende passages") snel en betrouwbaar op schaal. Zonder database doe je bij elke query een brute-force vergelijking met elke embedding, en dat loopt vast zodra je meer dan een paar duizend documenten hebt.

De retrievallaag goed krijgen is vaak het verschil tussen een RAG-assistent die scherp aanvoelt en een die hallucineert. Wil je het bredere plaatje van hoe retrieval in een kennisassistent past, dan schetst onze gids over RAG-assistenten op je eigen kennisbank het geheel, en twijfel je nog tussen retrieval en fine-tunen als aanpak, begin dan bij RAG versus fine-tunen.

Hoe vectorzoeken onder de motorkap echt werkt

Vrijwel elke serieuze vectordatabase leunt op approximate nearest neighbour (ANN)-zoeken, omdat exact zoeken te traag is op schaal. Het dominante algoritme is HNSW — Hierarchical Navigable Small World graphs — geïntroduceerd door Malkov en Yashunin in hun veelgeciteerde paper, Efficient and robust approximate nearest neighbor search using HNSW graphs. HNSW bouwt een gelaagde graaf die je in ongeveer logaritmische tijd doorloopt en ruilt een fractie recall in voor enorme snelheidswinst. De oudere IVF-aanpak (inverted file) clustert vectoren en doorzoekt alleen de dichtstbijzijnde clusters; dat kost minder geheugen, maar is meestal trager en lastiger af te stellen.

Twee knoppen tellen bij al deze engines. Recall is het aandeel echte nearest neighbours dat je daadwerkelijk ophaalt — draai je die omhoog, dan stijgt de latency. Latency is je zoeksnelheid. Elke vectordatabase is een onderhandeling tussen die twee, en de goede laten je de balans afstellen. Systemen die de knoppen volledig verbergen zijn makkelijker om mee te beginnen, maar lastiger te optimaliseren als de recall tegenvalt.

De vier kandidaten

pgvector — vectorzoeken binnen PostgreSQL

pgvector is een open-source extensie die vectorkolommen en similarity search aan PostgreSQL toevoegt. De documentatie en broncode staan op de pgvector GitHub-repository, en het ondersteunt zowel HNSW- als IVFFlat-indexen. De aantrekkingskracht is helder: draait je applicatie al op Postgres, dan bewaar je embeddings pal naast je relationele data, gebruik je de SQL, back-ups en toegangsrechten die je al vertrouwt, en voeg je geen nieuwe infrastructuur toe. Voor heel veel RAG-systemen — interne kennisbanken, documentassistenten, de meeste mkb-workloads — is dat de pragmatische standaard. De keerzijde: je zit vast aan de kenmerken van single-node Postgres. Zeer grote collecties duwen de indexbouw en het onderhoud omhoog, en zodra je één goed uitgeruste instance ontgroeit, kom je uit bij replica's, partitionering of een overstap naar een dedicated engine.

Qdrant — een doelgebouwde, filter-first engine

Qdrant is een open-source vectordatabase geschreven in Rust, beschikbaar als self-hosted of als beheerde Qdrant Cloud. De grootste kracht is gefilterd zoeken: het implementeert een filterbare HNSW-index die de graaf verbonden houdt, óók als je metadata-voorwaarden toepast — precies wat je nodig hebt als een query toegangsrechten of een datumbereik moet respecteren. Qdrant legt het mechanisme goed uit in hun eigen artikel over filterbare HNSW. Voor teams die sterke prestaties, flexibele deployment en echt goed filteren willen zonder de prijs van een beheerde dienst, is het een sterke keuze — met als prijs dat je bij self-hosting zelf infrastructuur draait.

Weaviate — hybride zoeken en een modulair ecosysteem

Weaviate is een open-source vectordatabase die inzet op hybride zoeken — dense vector-similarity combineren met sparse keyword-matching (BM25-achtig) in één query — en biedt een modulair ecosysteem voor embeddinggeneratie en andere uitbreidingen. Als je retrievalkwaliteit baat heeft bij het mengen van semantische en keyword-signalen (vaak bij jargon, productcodes of namen die embeddings slecht aankunnen), dan is Weaviate's native hybride ondersteuning een echt voordeel. Het is beschikbaar als self-hosted of als beheerde clouddienst. De keerzijde is een groter conceptueel oppervlak om te leren dan pgvector en, net als bij Qdrant, echt beheerwerk als je het zelf host.

Pinecone — volledig beheerd, zero-ops

Pinecone is een propriëtaire, volledig beheerde vectordatabase. Je draait geen servers, stelt geen indexen af en denkt niet na over sharding — je stuurt vectoren en queries naar een API en de rest wordt geregeld. Voor teams die snel willen leveren en retrieval als een black box willen behandelen, is dat aantrekkelijk. De andere kant is de gebruikelijke afweging van een beheerde dienst: minder controle over de index en recall-afstelling, een terugkerende rekening die met de schaal meegroeit, en je embeddings die op een platform van derden staan — wat, zoals we zullen zien, onder EU-regels een reële overweging is.

Metadata-filtering en hybride zoeken: de details die kwaliteit bepalen

In productie-RAG doorzoek je bijna nooit de hele corpus. Je filtert — op tenant, documenttype, toegangsniveau, actualiteit — en rangschikt dan op gelijkenis. Hoe goed een database gefilterd vectorzoeken doet, telt vaak zwaarder dan de ruwe benchmarksnelheid. Naïef filteren (ophalen op vector, daarna rijen weggooien die het filter niet halen) verwoest de recall als het filter selectief is. Filterbewust indexeren, zoals in Qdrant's filterbare HNSW, ontwijkt die valkuil. pgvector regelt filtering via gewone SQL WHERE-clausules — intuïtief, maar met eigen prestatiekenmerken op schaal. Weaviate's hybride zoeken voegt een compleet extra dimensie toe door keyword- en vectorrelevantie te mengen.

De praktische les: benchmark met jouw filters en jouw querypatronen, niet met een generieke dataset. Een database die het snelst lijkt op een ongefilterde test met een miljoen vectoren, kan de traagste zijn zodra je de voorwaarden toevoegt die je echte applicatie nodig heeft.

Beheerd versus self-hosted: de afweging die het veld echt splijt

Strip de featurelijsten weg en het besluit komt neer op één vraag: wil je infrastructuur draaien of iemand anders ervoor betalen? Beheerde diensten als Pinecone (en de cloudvarianten van Qdrant en Weaviate) halen de beheerlast weg — geen upgrades, geen capaciteitsplanning, geen pager om 2 uur 's nachts. Je ruilt geld en controle in voor tijd. Zelf pgvector, Qdrant of Weaviate hosten kost doorgaans veel minder op klein tot middelgroot niveau en geeft je volledige controle over afstelling en datalocatie, maar je bent zelf verantwoordelijk voor betrouwbaarheid, back-ups en upgrades.

Voor de meeste mkb'ers met wie we werken is het eerlijke antwoord: begin met pgvector als je al Postgres draait, want dat scheelt een compleet bewegend onderdeel. Grijp naar een dedicated engine wanneer gefilterde zoekkwaliteit, schaal of hybride retrieval de extra beheerlast rechtvaardigt. Dit is dezelfde build-versus-buy-logica die we bij alle AI-projecten toepassen — en wil je hulp om die op je eigen stack te leggen, dan bestaan onze diensten data engineering en LLM-optimalisatie precies daarvoor.

Schalen: waar elke optie begint te kraken

Schaal verandert alles. Aan de onderkant — tot ruwweg een miljoen vectoren — zijn de verschillen klein, en presteert pgvector met een goed geconfigureerde HNSW-index vergelijkbaar met dedicated engines. Groeien collecties naar miljoenen en tientallen miljoenen, dan begint single-node Postgres te kraken: indexbouw duurt langer, onderhoudsoperaties concurreren met queryverkeer, en je gaat read replica's of partitionering plannen. Doelgebouwde engines zijn ontworpen voor dat regime, met sharding en gedistribueerde deployment als eersteklas onderwerpen. Pinecone abstraheert het schalen volledig weg, en dat is precies waarvoor je betaalt.

De valkuil om te vermijden is over-engineeren voor een schaal die je niet hebt. De meeste RAG-systemen overschrijden nooit een paar miljoen vectoren. Een zware gedistribueerde database kiezen voor een corpus die comfortabel in Postgres past, is een veelgemaakte en dure fout.

Kosten: wat je echt betaalt

Kosten splitsen langs dezelfde beheerd-versus-self-hosted-lijn. Self-hosted open-source engines hebben geen licentiekosten; je betaalt voor de compute en opslag die je inricht, en dat is op klein tot middelgroot niveau doorgaans veel goedkoper dan een beheerd equivalent — mits je de engineeringtijd om ze te draaien eerlijk meerekent. Beheerde platforms rekenen op opgeslagen vectoren, queries en doorvoer, en die rekening groeit mee met het gebruik. De juiste vergelijking is total cost of ownership: een "goedkoop" self-hosted cluster dat een week engineering per maand opslokt, is niet goedkoop. Reken beide paden door tegen je echte volume voordat je een keuze maakt.

EU-dataresidentie en AVG: de doorslaggevende factor in Nederland

Voor Nederlandse en Europese organisaties is de plek waar je embeddings staan geen voetnoot — het kan de doorslaggevende factor zijn. Embeddings afgeleid van persoonlijke of vertrouwelijke data kunnen zelf persoonsgegevens zijn onder de AVG, waardoor de locatie en verwerker van je vectorstore recht binnen je gegevensbeschermingsplichten vallen. De European Data Protection Board biedt hier de gezaghebbende richtlijnen, en de Nederlandse toezichthouder handhaaft ze. Een volledig beheerde in de VS gevestigde dienst kan doorgifte-waarborgen en een zorgvuldige contractuele toets vergen; een self-hosted engine in een EU-regio, of een beheerde aanbieder met EU-dataresidentie, omzeilt veel van die wrijving.

Dit is geen juridisch advies, en je moet je specifieke situatie met een gekwalificeerd adviseur bevestigen — maar als vuistregel voor engineers leunen EU-organisaties die gereguleerde of gevoelige data verwerken naar self-hosted pgvector of Qdrant in een EU-regio, of naar een beheerde aanbieder die EU-residentie contractueel garandeert. Het is veel makkelijker om residentie vanaf het begin in te bouwen dan om het achteraf, na een auditbevinding, alsnog toe te voegen.

Hoe je kiest: een kort beslissingskader

• Al op Postgres, corpus onder een paar miljoen vectoren? Begin met pgvector. Het is het pad met de minste wrijving en dekt de meeste mkb-RAG-workloads.
• Veel gefilterd zoeken of strikte dataresidentie, en bereid infra te draaien? Qdrant, self-hosted of in een EU-cloudregio, is de sterke standaard.
• Vraagt retrievalkwaliteit om hybride (keyword + vector) zoeken? Weaviate's native hybride ondersteuning verdient zich terug.
• Wil je zero-ops en accepteer je een in de VS beheerd platform (met doorgifte-waarborgen)? Met Pinecone lever je het snelst.
• Gereguleerde data in de EU? Laat residentie het besluit leiden en optimaliseer daarna voor prestaties binnen die randvoorwaarde.

Wat je ook op je shortlist zet, valideer het tegen je eigen documenten, filters en querypatronen voordat je kiest. Benchmarks op andermans dataset zijn een startvermoeden, geen antwoord.

Je embeddingmodel telt net zo zwaar als je database

Teams zijn geobsedeerd door de database en behandelen het embeddingmodel als bijzaak, en dat is de omgekeerde volgorde. Het model bepaalt de dimensionaliteit van je vectoren, en dimensionaliteit drijft zowel de opslagkosten als de zoeksnelheid: hoger-dimensionale embeddings vangen meer nuance, maar kosten meer geheugen en meer tijd om te vergelijken. Een model dat vectoren van 1.536 dimensies produceert, kost merkbaar meer om op te slaan en te doorzoeken dan een van 384 dimensies, en dat verschil stapelt op over miljoenen records. Kies het kleinste model dat de retrievalkwaliteit geeft die je nodig hebt, niet het grootste dat beschikbaar is.

Er is een tweede, scherpere adder: je embeddings zijn alleen vergelijkbaar met andere die door hetzelfde model zijn gemaakt. Wissel je van model, dan moet je je hele corpus opnieuw embedden, want vectoren van verschillende modellen leven in verschillende ruimtes. Dat maakt de modelkeuze een langere-termijnverbintenis dan de database zelf, dus weeg die bewust af. Veel teams gebruiken ook quantisatie — vectoren comprimeren naar kleinere numerieke types — om geheugen en kosten te drukken tegen een kleine, vaak acceptabele recall-boete. Alle vier de databases hier ondersteunen er een vorm van, en het is de moeite waard om te testen zodra je corpus groeit.

De operationele realiteit die mensen onderschatten

De demo werkt altijd. Productie is waar de oncharmante details bijten, en dat zijn precies de details die een goede vergelijking je moet laten onder ogen zien. Indexbouwtijd is de eerste: een HNSW-index bouwen over een grote collectie is niet direct klaar, en herbouwen na een bulkimport kan echt tijd kosten, waarin queries trager kunnen zijn of de index onbeschikbaar. Plan je ingestie eromheen in plaats van het onder belasting te ontdekken.

Geheugengebruik is de tweede. HNSW-indexen zijn geheugenhongerig omdat de graaf in RAM staat voor snelle traversal; onderprovisioneer en de prestaties storten in. Dan is er recall-drift — terwijl je vectoren toevoegt, bijwerkt en verwijdert, kan de retrievalkwaliteit stilletjes verslechteren tot je herindexeert, dus je hebt monitoring nodig die kwaliteit bewaakt, niet alleen uptime. Back-ups en disaster recovery maken het af: met pgvector erf je vrijwel gratis Postgres' volwassen tooling, terwijl een dedicated engine zijn eigen back-up- en herstelverhaal vergt dat je zelf moet ontwerpen en testen. Niets hiervan is een reden om een bepaalde database te mijden — het is een reden om het beheerwerk eerlijk te begroten, en om een beheerde dienst zwaarder te wegen als je team er geen zin in heeft.

Chunking: de retrievalhendel die de meeste teams negeren

Een waarheid waar geen enkele databaseleverancier mee opent: hoe je je documenten in chunks knipt vóór het embedden, beïnvloedt de retrievalkwaliteit méér dan welke van deze vier engines je draait. Chunk je te groot, dan versmelt elke vector meerdere ideeën, waardoor het model een muur van grotendeels irrelevante tekst ophaalt. Chunk je te klein, dan versplinter je de context en haal je fragmenten op die alleen samen met niet-opgehaalde buren betekenis hebben. De optimale maat hangt af van je content — dichte contracten vragen andere chunking dan spraakzame supporttickets — en het loont om daarop te itereren voordat je de database de schuld geeft van zwakke antwoorden. Overlappende chunks en rijke metadata meegeven (bron, sectie, datum) zodat je precies kunt filteren, zijn twee goedkope winsten die op elke engine hier beschikbaar zijn. Krijg je chunking en filtering goed, dan verslaat een bescheiden pgvector-opzet elke keer een slecht afgestelde premiumdatabase.

Waar Crux Digits past

De meeste teams hebben niet de meest geavanceerde database nodig — ze hebben de retrievallaag nodig die past bij hun data, hun schaal en hun compliancerealiteit, ingebouwd in een systeem dat ook echt live gaat. Dat is het werk dat wij doen: leveranciersonafhankelijk, engineering-first en eerlijk over afwegingen. Ben je een RAG-systeem aan het scopen en wil je het fundament in één keer goed leggen, bekijk dan onze transparante prijzen of boek een gratis consult en we brengen je eerste use case samen in kaart — meestal met een werkend prototype tegen het tweede gesprek.

Veelgestelde vragen