RAG-stack kiezen: hosted, Qdrant of pgvector voor SaaS

Het is donderdag, 17:04, in een kantoor in Utrecht. De product lead van een Nederlandse B2B SaaS met €9M ARR krijgt net een ping van sales: de klantgerichte RAG-agent noemde de verkeerde SLA aan een prospect tijdens een live call. De CTO opent Slack en beseft dan dat ze niet weet welk bestand in welke repository de chunker bevat. Achter de agent zitten 312 PDF's, 1.400 Confluence-pagina's en een Notion-export. De vraag op tafel is niet welke vector database het snelst is. De vraag is wie dit in de komende twintig minuten oplost, en hoe de rekening er aan het eind van de maand uitziet.

Dit is de afweging die we maken met elke Nederlandse B2B SaaS onder de €18M die ons vraagt om een klantgerichte kennis-agent te bouwen. In 2026 zijn er drie serieuze opties voor een team van deze omvang. Hosted file-search bij de model-leverancier. Een self-hosted Qdrant-stack met een reranker. Een Postgres pgvector-opzet met BM25 hybrid search in de database die je toch al draait. Geen van de drie is fout. Alle drie zijn fout voor iemand.

De twee assen die het echt bepalen

De meeste architectuurposts scoren RAG-stacks op recall@10, latency en "developer experience". Die dingen tellen, maar daar gaat je project in jaar twee niet aan kapot. De twee assen waarop wij scoren zijn botter.

Ten eerste: kosten per tenant bij 50.000 pagina's. Niet kosten per request. Niet kosten per token in isolatie. De volledige maandelijkse kosten om het corpus van één klant geïndexeerd, geëmbed en bevraagd te houden bij hun werkelijke volume, plus opnieuw embedden zodra je van model wisselt. Vijftigduizend pagina's is het punt waarop de prijscurve van elke optie ophoudt lineair te zijn. Daaronder werkt alles. Daarboven ontdek je welk contract je hebt getekend.

Ten tweede: wie repareert de chunker om 17:00 op donderdag. Als de agent een fout antwoord geeft, moet iemand de indexing-pipeline openen, het document vinden, kijken hoe het is gesplitst, de split aanpassen, de getroffen pagina's opnieuw embedden en het verifiëren. Die persoon moet bestaan, bereikbaar zijn en lees-toegang hebben tot de code die het splitsen doet. Als het splitsen achter een vendor-API gebeurt die je niet kunt zien, is het antwoord op "waarom noemde 'ie de verkeerde SLA" simpel: "we hebben een ticket aangemaakt".

Optie A: hosted file-search

Anthropic, OpenAI en een handvol anderen bieden file-search nu aan als managed feature binnen hun assistant- of agent-API's. Je upload documenten, de vendor regelt chunking, embedding, retrieval en reranking, en je krijgt citaties terug in de response. Voor een team van vier zonder dedicated infra-engineer is dit een serieus antwoord.

De rekensom bij 50.000 pagina's gaat ongeveer zo. Storage- en indexing-kosten per tenant zijn bescheiden, vaak een post van enkele euro's. De kostenstapel zit in inference: elke query leest context, en die context wordt afgerekend tegen input-token-tarieven. Bij een klant met 80 agent-conversaties per dag en gemiddeld 4.000 tokens aan opgehaalde context per beurt, zit je op een paar honderd euro per tenant per maand op een mid-tier model. Niet catastrofaal. Voorspelbaar.

De pijn zit niet in de rekening. De pijn zit in de chunker. Je kunt 'm niet zien. Wanneer sales het foute SLA-antwoord meldt, opent je CTO het document, ziet dat de SLA-tabel een tweekoloms-PDF is met een voetnoot, en realiseert zich dat de chunker van de vendor de voetnoot waarschijnlijk los heeft geknipt van de rij. Haar opties: de bron-PDF herschrijven, of de prompt aanpassen om te compenseren. De chunking-strategie zelf kan ze niet veranderen. De fix landt in het brondocument, niet in de code.

Er zit ook nog een randje aan data-positionering. Hosted file-search betekent dat je geïndexeerde content op infrastructuur van de vendor staat, vaak buiten de EU. De EDPB-aanbevelingen na Schrems II bepalen nog steeds de inkooptoetsing bij Nederlandse kopers in publieke sector, zorg en finance. Als dat jouw klanten zijn, wordt hosted file-search een inkoopgesprek, geen technisch gesprek. We zagen in 2026 al twee deals stuklopen op precies dit punt.

Wanneer wij ervoor kiezen

Eén-productbedrijf, minder dan tien betalende tenants, geen infra-engineer, alleen Engels of alleen Nederlands corpus onder de 20.000 pagina's per tenant, en een koperbasis die niet schrikt van Amerikaanse data residency. Ship 'm maandag. Door.

Optie B: Qdrant plus een reranker

Self-hosted Qdrant op een kleine VM, een open embedding-model achter een minuscule FastAPI-service, en een reranker zoals bge-reranker-v2-m3 voor de uiteindelijke top-k. Dit is de stack die wint op kwaliteit voor rommelige, meertalige corpora. Het is ook de stack die het meeste van het team vraagt.

Kosten per tenant bij 50.000 pagina's dalen scherp. Eén Qdrant-node op een box van €60 per maand bedient comfortabel een handvol tenants als je per collection partitioneert. Embedding is een eenmalige kost per documentversie. De query-time-kost is bijna volledig de LLM-call zelf, omdat retrieval lokaal is. We hebben klanten die deze stack draaien voor minder dan €40 per tenant per maand all-in, reranker meegerekend, op productieverkeer.

De 17:00-vraag heeft hier een echt antwoord. Je engineer opent indexer/chunk.py, ziet de functie die de SLA-PDF splitst, merkt dat de tabel-aware tak nooit is aangesloten, fixt 'm, embed het getroffen document opnieuw, en om 17:18 geeft de agent het juiste antwoord. Dat is de droom. De prijs van die droom: iemand moet dat bestand bezitten. Als je team uit drie mensen bestaat en niemand on-call wil zijn voor Qdrant-upgrades, koop je er een tweede product bij om te onderhouden.

from qdrant_client import QdrantClient
from qdrant_client.http.models import Distance, VectorParams

client = QdrantClient(url="http://qdrant:6333")

client.create_collection(
    collection_name=f"tenant_{tenant_id}",
    vectors_config=VectorParams(size=1024, distance=Distance.COSINE),
)

# Hybrid: dense vectors in Qdrant, sparse BM25 in a sidecar.
# Rerank the union with a cross-encoder before sending top-5 to the LLM.

Wanneer wij ervoor kiezen

Multi-tenant SaaS met meer dan tien betalende klanten, een corpus dat Nederlands en Engels mengt, een koperbasis die EU data residency eist, en minstens één engineer die de indexer wil bezitten. We hebben dit het afgelopen jaar voor twee klanten gebouwd, en het is onze default zodra het team de spierkracht heeft.

Optie C: Postgres pgvector met BM25 hybrid

Als je al Postgres draait, en je hebt al één engineer die het goed kent, is pgvector plus de pg_search BM25-extensie de saaiste en meest onderschatte optie van de drie. Je zet twee extensies op de database waarvan je toch al een back-up maakt, en je retrieval woont naast de rijen waar 'ie over gaat.

Het kostenverhaal is het schoonste van de drie. Je betaalt voor storage en compute op een database die je sowieso zou draaien. Bij 50.000 pagina's per tenant draait een bescheiden Postgres-instance een dozijn tenants zonder kreunen. We hebben een klant die dit draait voor €18 per tenant per maand, volledig belast, op Hetzner.

De 17:00-vraag is hier het makkelijkst te beantwoorden, want de chunker leeft naast de applicatiecode en de data leeft in dezelfde database als de tenant-rij. Je engineer schrijft een SQL-query in de staging-console, ziet de foute chunk, fixt de splitter, draait een backfill, en gaat naar huis. Het nadeel is recall. Pure pgvector verliest van een goed afgestelde Qdrant + reranker-stack op moeilijke queries, en het gat wordt groter bij meertalige corpora. De BM25-hybrid dicht het meeste, niet alles.

Wanneer wij ervoor kiezen

Je draait al Postgres in productie. Je hebt één engineer die er thuis in is. Je corpus per tenant blijft onder de 100.000 pagina's. Je wilt één systeem minder om te back-uppen, te monitoren en uit te leggen aan de volgende hire.

De scoringssheet die we echt gebruiken

We scoren elke kandidaat-RAG-stack op zes regels voordat we ons committeren. Kosten per tenant op de verwachte schaal. Wie bezit de chunker. Data residency-positie. Latency-budget voor het eerste token van de agent. Kosten om over achttien maanden van embedding-model te wisselen. Kosten om de elfde tenant erbij te zetten.

Die laatste is de val. Hosted file-search is bij tenant één het goedkoopst en bij tenant vijftig het duurst. Qdrant is precies omgekeerd. pgvector is vlak over de curve totdat je tegen het recall-plafond aanloopt. Als je met droge ogen niet kunt zeggen hoeveel tenants je over achttien maanden hebt, scoor dan op de middelste kolom en kies de optie die je toelaat van gedachten te veranderen zonder migratie.

Wat we voor een Nederlandse klant deden

Toen we dit voorjaar voor een Nederlandse logistiek-SaaS de klantgerichte kennis-AI-agent bouwden, was het ding waar we tegenaan liepen dat hun corpus voor 60% Nederlandse vervoersregulatie-PDF's met tabellen was, voor 40% Engelse API-docs, en de koper was een inkoper bij een publieke instantie die niet zou tekenen op Amerikaanse data residency. We zijn uitgekomen op Qdrant plus een meertalige reranker op een Hetzner-box in Falkenstein, en hebben de chunker in dezelfde repository gezet als de applicatie, zodat dezelfde engineer die de agent bezit ook de splits bezit.

Voordat je een stack kiest, doe deze audit van vijf minuten. Open je grootste brondocument. Lees de slechtst opgemaakte pagina. Vraag jezelf af wie, bij naam, de chunker gaat fixen wanneer die pagina fout wordt geciteerd. Als je geen naam kunt noemen, kies je geen architectuur. Je kiest een zondebok.