pgvector eller Qdrant — vilken ska jag självhosta?

Om du redan kör Postgres (eller vill ha en databas för både din app-data och embeddings) är pgvector det minst ansträngande valet — det är bara ett tillägg. Om du har miljoner vektorer eller vill ha en purpose-built motor med snabb filtrering är Qdrant värt den separata tjänsten. För de flesta agenter som börjar är pgvector på Postgres gott och väl.

Hur mycket RAM behöver en vektordatabas?

Mer än du skulle gissa, för bra sökning vill ha indexet i minnet. En grov regel: ett par hundratusen embeddings sitter bekvämt i 2 GB; när du väl når låga miljoner, planera för 4 GB+ och tuna indexet. Börja på 2 GB, titta på minnet, ändra storlek när sökningen blir långsam.

Varför självhosta en vektorlagring istället för en managed?

Två skäl folk faktiskt gör det: dina embeddings innehåller ofta din privata data (anteckningar, dokument, kundinnehåll), och en självhostad lagring håller det på en server du kontrollerar. Och det är fast-kostnad — en managed vektortjänst fakturerar per vektorer och frågor, medan en VPS är ett månatligt tal utan per-fråga-mätare.

Kan en vektor-DB och min agent köra på samma VPS?

Ja, för små till medelstora arbetsbelastningar — att co-locata agenten och en pgvector/Qdrant-instans på en box är enkelt och skär latensen till nära noll. Dela dem på separata servrar bara när en börjar svälta ut den andra på RAM, vilket är ett trevligt problem att ha senare, inte en dag-ett-oro.

Tar embeddings mycket disk?

En enda embedding är ett par kilobyte, så en miljon av dem är ett par gigabyte plus index-overhead — betydelsefullt men inte enormt. 25–45 GB disk täcker en betydande minneslagring för de flesta agenter. RAM, inte disk, är oftast den första gränsen du träffar.

Hosta en vektordatabas för AI-agent-minne på en VPS

En AI-agent utan minne fastnar i att återintroducera sig själv varje konversation. Fixen är en vektordatabas — den lagrar embeddings av dina dokument, anteckningar eller tidigare chattar så att agenten kan återkalla de relevanta bitarna på begäran (det är "R":et i RAG). Du kan hyra det som en managed tjänst, eller så kan du köra det själv på en VPS och hålla din data — som ofta är din privata data — på en box du kontrollerar. Här är hur, och vad det faktiskt kostar i RAM.

Två bra alternativ

Du behöver inget exotiskt. Två vägar täcker nästan alla:

pgvector — ett Postgres-tillägg. Om du redan kör Postgres (eller är okej med det) lägger detta till vektorsökning i databasen du redan har. En tjänst, en säkerhetskopia, SQL du kan. Den minst ansträngande starten med bred marginal.

Qdrant — en purpose-built vektormotor. Sträck dig efter den när du har många vektorer (låga miljoner+) eller vill ha snabb metadata-filtrering och en dedikerad API. Det är en separat tjänst att köra, men den är byggd för exakt detta jobb.

För de flesta agenter som hittar fötterna är pgvector det rätta första svaret. Flytta till Qdrant när du har vuxit ur det, inte innan.

RAM-verkligheten (detta är delen folk underskattar)

Vektorsökning är snabb för att indexet lever i minnet — så RAM, inte disk, är din verkliga begränsning. En grov guide:

Ett par hundratusen embeddings — bekvämt i 2 GB.
Låga miljoner — planera för 4 GB+ och tuna indexet.
Disk är den lätta delen: en miljon embeddings är bara ett par GB, så 25–45 GB täcker en seriös lagring.

Så dimensionera för indexet, inte filen. (Samma logik som den allmänna dimensioneringsguiden — det tunga är inte uppenbart förrän du mäter.)

Snabbstart: pgvector

På en box med Postgres (Docker är enklast — samma mönster som att självhosta n8n):

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);

Din agent infogar content + dess embedding, och frågar sedan med ORDER BY embedding <=> $query_embedding LIMIT 5 för att hämta de närmaste minnena. Det är hela loopen.

Föredrar Qdrant? Det är en enda Docker-container som exponerar en HTTP/gRPC-API; du skapar en collection med din vektorstorlek och upsertar punkter. Samma idé, dedikerad motor.

Kan den dela en box med agenten?

Ja — för små-till-medelstora minneslagringar, kör vektor-DB:n på samma VPS som agenten. Det är enklare och latensen är i princip noll. Dela dem på separata servrar bara när en börjar tränga ut den andra ur RAM. Det är ett senare, gott-problem-att-ha-beslut, inte ett dag-ett.

Ärliga förbehåll

RAM är väggen, och den är tyst. Sökning förblir snabb tills indexet inte längre får plats i minnet, sedan degraderas det. Titta på minnet och ändra storlek innan det biter — vänta inte på att långsamma frågor ska tala om det.
Embeddings kostar tokens att skapa. Varje dokument du embeddar är ett API-anrop till en embedding-modell. Lagringen är billig att hosta; att generera vektorerna är den återkommande kostnaden — relevant för vad det faktiskt kostar att köra en agent.
Säkerhetskopiera den. Din agents minne är data som all annan. Om det spelar roll, snapshota det.

Inom det är en självhostad vektorlagring ett rent sätt att ge en agent varaktigt minne utan att lämna din privata data till en tredje part. Börja med pgvector på en 2 GB-box, håll ett öga på RAM, och väx in i Qdrant eller ett större plan bara när siffrorna säger åt dig.