pgvector of Qdrant — welke moet ik zelf hosten?

Als je al Postgres draait (of één database wilt voor zowel je app-data als embeddings), is pgvector de minst-inspannende keuze — het is gewoon een extensie. Als je miljoenen vectoren hebt of een purpose-built engine met snelle filtering wilt, is Qdrant de aparte service waard. Voor de meeste agents die net beginnen, is pgvector op Postgres ruim voldoende.

Hoeveel RAM heeft een vector-database nodig?

Meer dan je zou raden, want goede zoekopdrachten willen de index in het geheugen. Een ruwe regel: een paar honderdduizend embeddings zitten comfortabel in 2 GB; zodra je lage miljoenen bereikt, reken op 4 GB+ en tune de index. Begin bij 2 GB, kijk naar geheugen, herschaal wanneer zoeken vertraagt.

Waarom een vector store zelf hosten in plaats van een managed?

Twee redenen waarom mensen het echt doen: je embeddings bevatten vaak je private data (notities, docs, klantcontent), en een self-hosted store houdt dat op een server die je beheert. En het is vaste kosten — een managed vector-service factureert per vector en query, terwijl een VPS één maandelijks getal is zonder per-query-meter.

Kunnen een vector-DB en mijn agent op dezelfde VPS draaien?

Ja, voor kleine tot middelgrote workloads — de agent en een pgvector/Qdrant-instance co-locaten op één box is simpel en snijdt latency naar bijna nul. Splits ze alleen op aparte servers wanneer een de ander begint uit te hongeren voor RAM, wat een fijn probleem is om later te hebben, geen dag-één-zorg.

Nemen embeddings veel schijf in?

Een enkele embedding is een paar kilobytes, dus een miljoen ervan is een paar gigabytes plus index-overhead — betekenisvol maar niet enorm. 25–45 GB schijf dekt een substantiële geheugen-store voor de meeste agents. RAM, niet schijf, is meestal de eerste limiet die je raakt.

Host een vector-database voor AI-agent-geheugen op een VPS

Een AI-agent zonder geheugen zit vast zichzelf elke conversatie opnieuw voor te stellen. De fix is een vector-database — het slaat embeddings op van je documenten, notities of vroegere chats zodat de agent de relevante stukjes op aanvraag kan oproepen (dat is de "R" in RAG). Je kunt dat als een managed service huren, of je kunt het zelf draaien op een VPS en je data — wat vaak jouw private data is — op een box houden die je beheert. Hier is hoe, en wat het echt kost aan RAM.

Twee goede opties

Je hebt niets exotisch nodig. Twee paden dekken bijna iedereen:

pgvector — een Postgres-extensie. Als je al Postgres draait (of het niet erg vindt), voegt dit vector search toe aan de database die je al hebt. Eén service, één back-up, SQL die je kent. De minst-inspannende start met een ruime marge.

Qdrant — een purpose-built vector-engine. Grijp ernaar wanneer je veel vectoren hebt (lage miljoenen+) of snelle metadata-filtering en een dedicated API wilt. Het is een aparte service om te draaien, maar het is gebouwd voor precies deze klus.

Voor de meeste agents die hun weg vinden, is pgvector het juiste eerste antwoord. Ga naar Qdrant wanneer je het ontgroeid bent, niet eerder.

De RAM-realiteit (dit is het deel dat mensen onderschatten)

Vector search is snel omdat de index in het geheugen leeft — dus RAM, niet schijf, is je echte constraint. Een ruwe gids:

Een paar honderdduizend embeddings — comfortabel in 2 GB.
Lage miljoenen — reken op 4 GB+ en tune de index.
Schijf is het makkelijke deel: een miljoen embeddings is maar een paar GB, dus 25–45 GB dekt een serieuze store.

Dimensioneer dus voor de index, niet het bestand. (Zelfde logica als de algemene dimensioneringsgids — het zware ding is niet duidelijk tot je het meet.)

Snelstart: pgvector

Op een box met Postgres (Docker is het makkelijkst — zelfde patroon als n8n zelf hosten):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- match your embedding model's dimensions
);

-- after you have data, build an index for fast search:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

Je agent voegt content + zijn embedding in, en query't dan met ORDER BY embedding <=> $query_embedding LIMIT 5 om de dichtstbijzijnde herinneringen op te halen. Dat is de hele lus.

Liever Qdrant? Het is een enkele Docker-container die een HTTP/gRPC-API blootstelt; je maakt een collection met je vector-grootte en upsert punten. Zelfde idee, dedicated engine.

Kan het een box delen met de agent?

Ja — voor kleine-tot-middelgrote geheugen-stores, draai de vector-DB op dezelfde VPS als de agent. Het is simpeler en de latency is in principe nul. Splits ze alleen op aparte servers wanneer een de ander uit de RAM begint te dringen. Dat is een latere, fijn-probleem-om-te-hebben beslissing, geen dag-één.

Eerlijke kanttekeningen

RAM is de muur, en hij is stil. Zoeken blijft snel tot de index niet langer in het geheugen past, dan degradeert het. Kijk naar geheugen en herschaal voordat het bijt — wacht niet tot trage queries het je vertellen.
Embeddings kosten tokens om te maken. Elk document dat je embedt is een API-call naar een embedding-model. De store is goedkoop te hosten; het genereren van de vectoren is de terugkerende kost — relevant voor wat een agent draaien echt kost.
Maak er een back-up van. Het geheugen van je agent is data als elk ander. Als het ertoe doet, snapshot het.

Binnen dat is een self-hosted vector store een schone manier om een agent duurzaam geheugen te geven zonder je private data aan een derde partij te geven. Begin met pgvector op een 2 GB-box, houd RAM in de gaten, en groei in Qdrant of een groter plan alleen wanneer de cijfers je dat vertellen.