pgvector o Qdrant — quale dovrei fare self-hosting?

Se già usi Postgres (o vuoi un unico database sia per i dati della tua app sia per gli embedding), pgvector è la scelta di minor sforzo — è solo un'estensione. Se hai milioni di vettori o vuoi un motore dedicato con filtri veloci, Qdrant vale il servizio separato. Per la maggior parte degli agenti che iniziano, pgvector su Postgres basta e avanza.

Quanta RAM serve a un database vettoriale?

Più di quanto immagineresti, perché una buona ricerca vuole l'indice in memoria. Regola approssimativa: qualche centinaio di migliaia di embedding sta comodo in 2 GB; una volta raggiunti i milioni bassi, prevedi 4 GB+ e ottimizza l'indice. Parti da 2 GB, sorveglia la memoria, ridimensiona quando la ricerca rallenta.

Perché fare self-hosting di un vector store invece di uno gestito?

Due motivi per cui la gente lo fa davvero: i tuoi embedding contengono spesso i tuoi dati privati (note, documenti, contenuti dei clienti), e uno store self-hosted li tiene su un server che controlli. Ed è a costo fisso — un servizio vettoriale gestito fattura per vettori e query, mentre un VPS è un unico numero mensile senza contatore per query.

Un DB vettoriale e il mio agente possono girare sullo stesso VPS?

Sì, per carichi da piccoli a medi — co-locare l'agente e un'istanza pgvector/Qdrant su una sola macchina è semplice e riduce la latenza a quasi zero. Separali su server distinti solo quando uno inizia ad affamare l'altro di RAM, che è un bel problema da avere più tardi, non una preoccupazione del primo giorno.

Gli embedding occupano molto disco?

Un singolo embedding è qualche kilobyte, quindi un milione di essi è qualche gigabyte più l'overhead dell'indice — significativo ma non enorme. 25–45 GB di disco coprono un notevole store di memoria per la maggior parte degli agenti. Di solito il primo limite che incontri è la RAM, non il disco.

Ospitare un database vettoriale per la memoria di un agente AI su un VPS

Un agente AI senza memoria è bloccato a ripresentarsi a ogni conversazione. La soluzione è un database vettoriale — memorizza gli embedding dei tuoi documenti, note o chat passate così l'agente può richiamare le parti rilevanti su richiesta (è la "R" di RAG). Puoi noleggiarlo come servizio gestito, oppure gestirlo tu stesso su un VPS e tenere i tuoi dati — che spesso sono i tuoi dati privati — su una macchina che controlli. Ecco come, e quanto costa davvero in RAM.

Due buone opzioni

Non ti serve nulla di esotico. Due strade coprono quasi tutti:

pgvector — un'estensione di Postgres. Se già usi Postgres (o sei contento di farlo), questa aggiunge la ricerca vettoriale al database che hai già. Un servizio, un backup, l'SQL che conosci. L'inizio di minor sforzo con ampio margine.

Qdrant — un motore vettoriale dedicato. Ricorri a lui quando hai molti vettori (milioni bassi+) o vuoi filtri veloci sui metadati e un'API dedicata. È un servizio separato da gestire, ma è costruito esattamente per questo lavoro.

Per la maggior parte degli agenti che muovono i primi passi, pgvector è la prima risposta giusta. Passa a Qdrant quando l'hai superato, non prima.

La realtà della RAM (è la parte che la gente sottovaluta)

La ricerca vettoriale è veloce perché l'indice vive in memoria — quindi la RAM, non il disco, è il tuo vero vincolo. Una guida approssimativa:

Qualche centinaio di migliaia di embedding — comodo in 2 GB.
Milioni bassi — prevedi 4 GB+ e ottimizza l'indice.
Il disco è la parte facile: un milione di embedding è solo qualche GB, quindi 25–45 GB coprono uno store serio.

Quindi dimensiona per l'indice, non per il file. (Stessa logica della guida al dimensionamento generale — la cosa pesante non è ovvia finché non la misuri.)

Avvio rapido: pgvector

Su una macchina con Postgres (Docker è la via più facile — stesso schema del self-hosting di n8n):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- corrisponde alle dimensioni del tuo modello di embedding
);

-- dopo aver dei dati, costruisci un indice per una ricerca veloce:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

Il tuo agente inserisce content + il suo embedding, poi interroga con ORDER BY embedding <=> $query_embedding LIMIT 5 per estrarre i ricordi più vicini. Ecco tutto il ciclo.

Preferisci Qdrant? È un singolo container Docker che espone un'API HTTP/gRPC; crei una collezione con la tua dimensione del vettore e fai upsert dei punti. Stessa idea, motore dedicato.

Può condividere una macchina con l'agente?

Sì — per store di memoria da piccoli a medi, esegui il DB vettoriale sullo stesso VPS dell'agente. È più semplice e la latenza è praticamente zero. Separali su server distinti solo quando uno inizia a togliere RAM all'altro. È una decisione successiva, un bel problema da avere, non del primo giorno.

Avvertenze oneste

La RAM è il muro, ed è silenzioso. La ricerca resta veloce finché l'indice ci sta in memoria, poi degrada. Sorveglia la memoria e ridimensiona prima che morda — non aspettare che le query lente te lo dicano.
Gli embedding costano token da creare. Ogni documento che incorpori è una chiamata API a un modello di embedding. Lo store costa poco da ospitare; generare i vettori è il costo ricorrente — rilevante per quanto costa davvero far girare un agente.
Fanne il backup. La memoria del tuo agente è un dato come qualsiasi altro. Se conta, fanne uno snapshot.

Entro questo, un vector store self-hosted è un modo pulito per dare a un agente una memoria durevole senza consegnare i tuoi dati privati a una terza parte. Inizia con pgvector su una macchina da 2 GB, tieni d'occhio la RAM, e cresci verso Qdrant o un piano più grande solo quando i numeri te lo dicono.