Pinecone vs Qdrant vs pgvector: wat RAG echt kost

De founding partner zat tegenover ons in een vergaderruimte boven een bakkerij aan de Stratumseind in Eindhoven. Ik wil dat onze junior engineers een vraag aan het archief kunnen stellen en een echt antwoord krijgen, met de bron-PDF erbij, zei hij. Ik wil daar geen €40k per jaar aan uitgeven. Het bureau heeft 26 mensen en 2,1 miljoen documenten die teruggaan tot 2011.

Dus bouwden we de RAG-agent. Voornamelijk PDF's, wat DWG-metadata en een lange staart oude Word-bestanden. Opgedeeld in ongeveer 9,4 miljoen 768-dim vectors nadat we boilerplate hadden weggesneden. De lastige vraag was niet het LLM. Het was waar de vectors moesten staan.

Dit stuk is het bierviltje dat we hen lieten zien, met de echte cijfers uit hun echte verkeer.

De shortlist

Drie kandidaten haalden de finale.

1. Pinecone serverless in eu-west-1 (Ierland). De wij beheren geen infrastructuur-optie.
2. Qdrant Cloud op een managed cluster in Frankfurt. De managed maar voorspelbaar-optie.
3. pgvector op één Hetzner CCX43 in Falkenstein. De wij spreken al Postgres-optie.

Weaviate, Chroma Cloud en Vespa vielen af om redenen die voor deze klant relevant waren maar jou hier zouden vervelen. Kort verhaal: data-residency vereiste EU-hosting die het bureau zelf kon auditen, en het team moest het kunnen draaien zonder een aparte platform engineer aan te nemen.

De testopstelling

Zelfde corpus, zelfde embedding model (een 768-dim open model dat we op een kleine GPU-bak draaien), zelfde chunkingstrategie (windows van 1.800 tekens met 200 tekens overlap), zelfde hybride retrieval (vector plus BM25 reranker), zelfde evaluatieset van 412 echte engineeringvragen geschreven door de partners.

We laadden alle 9,4 miljoen vectors in elk systeem, draaiden de evalset vijf keer per systeem en maten drie dingen:

• Query-latency p50 / p95 / p99 vanuit een loadtest met 20 gelijktijdige gebruikers gedurende een uur.
• Kosten per 1.000 queries, inclusief opslag, reads, writes tijdens reindex en (voor Hetzner) afgeschreven serverkosten.
• Tijd om het volledige corpus opnieuw te indexeren, want het bureau voegt zo'n 4.000 documenten per week toe en herindexeert het embedding model elk kwartaal.

Queries gingen door de volledige pipeline van de agent, niet alleen de vectorlookup. Dus de latency-cijfers bevatten de BM25-join en de reranker. De interessante vergelijking is de delta tussen systemen met al het andere constant.

Pinecone serverless

De serverless-pricing van Pinecone bestaat uit reads, writes en opslag. Voor 9,4M vectors op 768 dim kwam onze opslagregel uit op ongeveer €38 per maand. De reads, bij de geprojecteerde 1.400 queries per dag van het bureau, kostten €11 per maand. Initial write om het corpus te laden: €19 eenmalig. Reindex met een nieuw embedding model per kwartaal: nog eens €19.

Steady state: ongeveer €49 / maand, oftewel €0,0011 per query op hun volume.

p95-latency over de test: 142 ms. p99: 287 ms.

Het cijfer dat pijn deed was niet de prijs. Het was de cold-read tail. Pinecone serverless pagineert indexes in en uit het geheugen op basis van toegangspatronen, en het archief van het bureau heeft long-tail queries (iemand stelt eens per jaar een vraag over een duikerberekening uit 2011). Op die queries zagen we af en toe een respons van 800ms. Geen dealbreaker. De partners merkten het wel.

Nog iets om op te letten: de kosten per query van Pinecone lijken klein totdat je een spraakzame agent hebt. De onze herschrijft de gebruikersvraag in drie sub-queries, raakt de index voor elk en doet een follow-up retrieval na de eerste generatie. Dat zijn vier reads per vraag. Vermenigvuldig dat voor je de rekening goedkeurt.

Qdrant Cloud

We zetten één node van 4 vCPU / 16 GB RAM op in Frankfurt op Qdrant Cloud. De HNSW-index voor 9,4M vectors paste in het geheugen met nog zo'n 3 GB over. Lijstprijs: €158 per maand.

p95-latency: 47 ms. p99: 89 ms.

Bij 1.400 queries per dag met vier reads elk, dat is ruwweg 168.000 reads per maand, dus €0,00094 per query. Op papier vrijwel gelijk aan Pinecone.

Het kwalitatieve verschil zat in voorspelbaarheid. Een vaste node, een vaste rekening, geen verrassing in de maand dat het bureau een interne hackathon draait en de agent eraan gaat. We hielden ook van de prestaties op filtered search. Het bureau filtert elke query op project-ID en documenttype, en de payload-index van Qdrant handelde dat af zonder de HNSW-degeneratie die je soms ziet als je filters op een pure vectorindex schroeft.

Reindex-tijd voor het volledige corpus op deze node: 38 minuten.

pgvector op Hetzner

Eén Hetzner CCX43 (16 dedicated vCPU, 64 GB RAM, 360 GB NVMe) in Falkenstein kost €127,99 / maand inclusief IPv4 en het EU-btw-vrije B2B-tarief. We draaiden Postgres 16 met pgvector 0.7 en het HNSW-indextype.

p95-latency: 34 ms. p99: 71 ms.

Kosten per query, afgeschreven: €0,00091. Effectief gelijk aan de twee managed opties.

Reindex-tijd: 2 uur 41 minuten. Trager dan Qdrant, maar het draait in een weekend-cron en niemand wacht erop.

De index-build zag er zo uit:

CREATE INDEX docs_embedding_hnsw
  ON document_chunks
  USING hnsw (embedding vector_cosine_ops)
  WITH (m = 24, ef_construction = 128);

-- Query with a payload filter
SELECT chunk_id, document_id, content
FROM document_chunks
WHERE project_id = ANY($1)
  AND doc_type = ANY($2)
ORDER BY embedding <=> $3
LIMIT 40;

De winst: het bureau draait al Postgres. Hun role-based access policies (engineers zien project X, ZZP'ers alleen gepubliceerde deliverables) leven in dezelfde database als de vectors, dus row-level security composeert gratis. Backups zijn pg_dump. Monitoring is het Postgres-dashboard dat de IT-lead toch al openhad.

Het verlies: we beheren het zelf. Patchen, point-in-time recovery, de dag dat pgvector een breaking change in zijn query planner uitbrengt. We voegden een Hetzner storage box toe voor WAL-archivering (€3,81 / maand) en een tweede CCX23 als warme replica (€31,90 / maand), wat de echte rekening op zo'n €163 / maand bracht. Iets meer dan Qdrant Cloud.

Wat we kozen

pgvector op Hetzner. Niet omdat het het goedkoopst was (dat was het niet, zodra we de replica meerekenden), en niet omdat het het snelst was (de p95-winst op Qdrant was 13 ms, wat geen mens via een chat-UI gaat merken). We kozen het omdat de IT-lead van het bureau in de bak kan SSH'en, het access control-verhaal de row-level security policies gebruikt die ze in 2019 al schreven, en omdat hij de volgende keer dat een junior vraagt waarom heeft de agent dat document opgehaald dat met een SQL-query kan uitzoeken.

De eerlijke samenvatting:

De economie kantelt bij schaal. Als het volume van het bureau verdrievoudigde, bleef Pinecone met afstand het goedkoopst. Als het 10x groeide en het aantal vectors verdubbelde, zou de vaste Qdrant-node een grotere node moeten worden en zou het gat verder dichtlopen. pgvector op Hetzner schaalt niet lineair voorbij ruwweg 50M vectors op één bak. Je kunt sharden, maar dan draai je een database en had je een DBA moeten aannemen.

Wat de vendor-calculators verbergen

Drie dingen die op elke pricing page ontbraken die we hierbij doornamen.

Agent-driven amplification. Moderne RAG-agents queryen niet één keer per gebruikersvraag. De onze doet er vier. Sommige twaalf. Als je projectie 1.000 vragen per dag is, ligt je read-volume waarschijnlijk tussen 4.000 en 12.000.

Reindex-kosten. Als je van embedding model wisselt (en dat ga je doen, het veld beweegt) betaal je de volledige write-kosten opnieuw, en soms een paar dagen dubbele opslag. Pinecone rekent writes. Qdrant en pgvector niet, maar Qdrants CPU gaat naar 100% tijdens de reindex en mogelijk heb je een grotere node nodig voor dat venster.

Egress. Pinecone en Qdrant sturen je queryresultaten over het publieke internet terug. Als je agent op een andere cloud draait, betaal je de egress van die cloud op weg naar het LLM. Met Hetzner en Postgres op hetzelfde private netwerk is die regel nul.

We hebben recall niet systematisch gebenchmarkt omdat alle drie de systemen binnen 1,5 punt van elkaar scoorden op de evalset van het bureau met default HNSW-instellingen. De retriever was niet de bottleneck voor antwoordkwaliteit. De chunkingstrategie wel, en dat is een ander stuk.

De kleinste nuttige volgende stap

Toen we de RAG-agent voor het Eindhovense bureau bouwden, was wat we tegenkwamen helemaal niet de vector store. Het was dat 18% van de PDF's gescand was zonder OCR-laag, en dat de partners jarenlang stilletjes op bestandsnaam hadden gezocht. Uiteindelijk draaiden we een eenmalige Tesseract-pass over het archief en schreven de OCR-tekst terug naar een sidecar-tabel, wat de retrieval recall op documenten ouder dan 2017 verdubbelde.

Als je dit kwartaal een vector store afmeet, is het kleinste nuttige dat je vandaag kunt doen: pak 50 echte vragen van de mensen die de agent straks gaan gebruiken, draai ze met de hand tegen je top drie kandidaten met hun default instellingen en leg de antwoorden en de latencies naast elkaar. De rekensom van de pricing page overleeft het contact met jouw corpus niet.