pgvector eller Qdrant — hvilken bør jeg self-hoste?

Hvis du allerede kører Postgres (eller vil have én database til både dine app-data og embeddings), er pgvector det mindst besværlige valg — det er bare en udvidelse. Hvis du har millioner af vektorer eller vil have en formålsbygget motor med hurtig filtrering, er Qdrant den separate tjeneste værd. For de fleste agenter, der starter ud, er pgvector på Postgres rigeligt.

Hvor meget RAM har en vektordatabase brug for?

Mere end du ville gætte, fordi god søgning vil have indekset i hukommelsen. En grov regel: et par hundrede tusinde embeddings sidder komfortabelt i 2 GB; når du når lave millioner, planlæg efter 4 GB+ og tun indekset. Start ved 2 GB, hold øje med hukommelsen, skalér op når søgning sløver.

Hvorfor self-hoste et vektorlager i stedet for et managed?

To grunde, folk faktisk gør det: dine embeddings indeholder ofte dine private data (noter, dokumenter, kundeindhold), og et self-hostet lager holder det på en server, du kontrollerer. Og det er flad-omkostning — en managed vektortjeneste fakturerer efter vektorer og forespørgsler, mens en VPS er ét månedligt tal uden en per-forespørgsel-måler.

Kan en vektor-DB og min agent køre på samme VPS?

Ja, til små til mellemstore arbejdsbyrder — at samplacere agenten og en pgvector/Qdrant-instans på én boks er simpelt og skærer latens til nær-nul. Del dem på separate servere kun, når den ene begynder at udsulte den anden for RAM, hvilket er et rart problem at have senere, ikke en dag-ét-bekymring.

Tager embeddings meget disk?

En enkelt embedding er et par kilobytes, så en million af dem er et par gigabytes plus indeks-overhead — betydeligt, men ikke enormt. 25–45 GB disk dækker et betydeligt hukommelseslager for de fleste agenter. RAM, ikke disk, er som regel den første grænse, du rammer.

Host en vektordatabase til AI-agent-hukommelse på en VPS

En AI-agent uden hukommelse sidder fast i at genintroducere sig selv hver samtale. Løsningen er en vektordatabase — den gemmer embeddings af dine dokumenter, noter eller tidligere chats, så agenten kan genkalde de relevante bidder på anmodning (det er "R'et" i RAG). Du kan leje det som en managed tjeneste, eller du kan køre det selv på en VPS og holde dine data — som ofte er dine private data — på en boks, du kontrollerer. Her er hvordan, og hvad det faktisk koster i RAM.

To gode muligheder

Du har ikke brug for noget eksotisk. To veje dækker næsten alle:

pgvector — en Postgres-udvidelse. Hvis du allerede kører Postgres (eller er glad for at gøre det), tilføjer dette vektorsøgning til den database, du allerede har. Én tjeneste, én backup, SQL du kender. Den mindst besværlige start med stor margin.

Qdrant — en formålsbygget vektormotor. Grib til den, når du har mange vektorer (lave millioner+) eller vil have hurtig metadata-filtrering og et dedikeret API. Det er en separat tjeneste at køre, men den er bygget til præcis dette job.

For de fleste agenter, der finder fodfæste, er pgvector det rigtige første svar. Skift til Qdrant, når du er vokset ud af det, ikke før.

RAM-virkeligheden (det er den del, folk undervurderer)

Vektorsøgning er hurtig fordi indekset bor i hukommelsen — så RAM, ikke disk, er din reelle begrænsning. En grov guide:

Et par hundrede tusinde embeddings — komfortabelt i 2 GB.
Lave millioner — planlæg efter 4 GB+ og tun indekset.
Disk er den lette del: en million embeddings er kun et par GB, så 25–45 GB dækker et seriøst lager.

Så dimensionér efter indekset, ikke filen. (Samme logik som den generelle dimensioneringsguide — den tunge ting er ikke indlysende, før du måler.)

Hurtig start: pgvector

På en boks med Postgres (Docker er lettest — samme mønster som self-hosting af n8n):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- match din embedding-models dimensioner
);

-- efter du har data, byg et indeks til hurtig søgning:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

Din agent indsætter content + dens embedding, forespørger derefter med ORDER BY embedding <=> $query_embedding LIMIT 5 for at trække de nærmeste minder. Det er hele løkken.

Foretrækker du Qdrant? Det er en enkelt Docker-container, der eksponerer et HTTP/gRPC-API; du opretter en samling med din vektorstørrelse og upserter punkter. Samme idé, dedikeret motor.

Kan den dele en boks med agenten?

Ja — til små-til-mellemstore hukommelseslagre, kør vektor-DB'en på samme VPS som agenten. Det er simplere, og latensen er dybest set nul. Del dem på separate servere kun, når den ene begynder at trænge den anden ud af RAM. Det er en senere, godt-problem-at-have-beslutning, ikke en dag-ét.

Ærlige forbehold

RAM er muren, og den er stille. Søgning forbliver hurtig, indtil indekset ikke længere passer i hukommelsen, så degraderer det. Hold øje med hukommelsen og skalér op før det bider — vent ikke på, at langsomme forespørgsler fortæller dig det.
Embeddings koster tokens at skabe. Hvert dokument, du embedder, er et API-kald til en embedding-model. Lageret er billigt at hoste; at generere vektorerne er den tilbagevendende omkostning — relevant for hvad det faktisk koster at køre en agent.
Backup den. Din agents hukommelse er data som alt andet. Hvis det betyder noget, snapshot det.

Inden for det er et self-hostet vektorlager en ren måde at give en agent varig hukommelse uden at aflevere dine private data til en tredjepart. Start med pgvector på en 2 GB-boks, hold øje med RAM, og voks ind i Qdrant eller et større abonnement kun, når tallene fortæller dig det.