Waarom heeft RAG zoveel RAM nodig?

Snel vector-zoeken wil de index resident in geheugen. Elke document-chunk wordt een embedding — een vector van een paar honderd tot een paar duizend floats — en bij miljoenen chunks telt dat op. Duw de index naar schijf en zoek-latency springt; de hele reden dat je zelf-hostte (snelheid + controle) behouden betekent hem in RAM houden.

Hoeveel RAM voor een gegeven corpus?

Ruw gevoel: een paar honderdduizend embeddings zitten prima in 2–4 GB. Lage miljoenen, met de app en OS eromheen, en je zit op 16–32 GB. Tientallen miljoenen of hoog-dimensie vectoren en je zit op 48–80 GB, en daarvoorbij splits je over servers. Dimensie en index-type schommelen dit veel, dus meet je eigen.

pgvector of een dedicated engine zoals Qdrant?

Als je al Postgres draait, is pgvector het minste-moeite-pad — één extensie, één database. Voor miljoenen vectoren met zwaar filteren verdient een purpose-built engine zijn eigen service. Begin met wat je al gebruikt; verhuis alleen wanneer zoeken traag wordt.

Waarom zelf-hosten in plaats van een managed vector-service?

Twee echte redenen: je embeddings encoderen vaak private data (docs, notities, klant-content), en zelf-hosten houdt dat op een server die je beheert. En het is vlakke kost — managed services meteren per vector en query, een VPS is één maandelijks getal zonder per-query-rekening.

Self-hosted RAG op schaal: hoeveel RAM een vector-index werkelijk opeet

Elke RAG-tutorial draait op een laptop met een paar honderd documenten, en het voelt moeiteloos. Dan richt je het op een echt corpus — de docs van een bedrijf, jaren aan tickets, een knowledge base — en plotseling is geheugen het hele gesprek.

RAG schaalt niet door CPU. Het schaalt door RAM.

Waarom de index geheugen wil

Retrieval werkt door elke chunk tekst om te zetten in een embedding — een vector, een paar honderd tot een paar duizend nummers lang. Zoeken betekent je query-vector vergelijken met allemaal, snel. "Snel" is het operatieve woord: voor lage latency moet de index in RAM leven. Op schijf werkt het, maar elke query betaalt een boete, en lage-latency retrieval was in de eerste plaats het punt van zelf-hosten.

Dus de geheugen-rekening schaalt met twee dingen: hoeveel chunks je hebt, en hoe breed elke vector is.

Echte cijfers, ruwweg

Meet je eigen — dimensie en index-type bewegen dit veel — maar als startgevoel:

Een paar honderdduizend embeddings — comfortabel in 2–4 GB. Een persoonlijke knowledge base, de docs van één product.
Lage miljoenen — met de app, de model-client, en het OS eromheen, plan voor 16–32 GB. Dit is een serieuze bedrijfs-knowledge-base of een multi-source RAG.
Tientallen miljoenen, of hoog-dimensie vectoren — nu zit je op 48–80 GB, en daarvoorbij over meerdere boxen. Grote document-landgoederen, multi-tenant retrieval, of je houdt meerdere indexen tegelijk warm.

Een multi-agent-systeem dat ook een grote index vasthoudt stapelt beide kosten op dezelfde box — zo verandert een 32 GB-plan stilletjes in een 64 GB-plan.

De engine-keuze, kort

Als je al Postgres draait, is pgvector de minste-moeite-optie — het is een extensie, geen nieuwe service om te babysitten. Wanneer je miljoenen vectoren hebt en snel gefilterd zoeken wilt, verdient een dedicated engine zoals Qdrant of Weaviate het aparte proces. Over-engineer het niet op dag één; draai wat je al gebruikt en split het uit wanneer zoeken echt vertraagt.

Waarom de moeite van zelf-hosten

Twee redenen waarom mensen dit werkelijk doen, en geen van beide is "om een paar dollar te besparen":

Privacy. Embeddings zijn niet abstract — ze encoderen de tekst waar ze vandaan kwamen. Je docs, de content van je klanten, je interne notities, omgezet in vectoren en verscheept naar de servers van een derde partij. Zelf-hosten houdt dat op een machine die je beheert. Als de data gevoelig genoeg is dat je ook in crypto betaalt zonder KYC, maakt een managed vector-cloud het hele punt ongedaan.

Vlakke kost. Managed vector-services rekenen per vector opgeslagen en query gedraaid. Een VPS is één maandelijks getal en je kunt het zo hard hameren als je wilt. Op schaal verslaat voorspelbaar gemeterd.

Wat dit betekent voor sizing

Begin met het meten van je corpus, niet met gokken. Krijg je embedding-aantal en dimensie, laad een sample, bekijk het resident geheugen, extrapoleer. Kies dan een plan met ruimte voor de index plus alles eromheen — de app, de model-client, ruimte om te groeien.

Voor alles voorbij een paar miljoen privé gehouden vectoren draait de Pro-lijn 32 tot 80 GB met een dedicated IP en nachtelijke back-ups, wat ertoe doet wanneer de index het product is en het verliezen pijn doet.