← Tutti gli articoli

pgvector vs vector DB dedicati: per casi italiani, basta Postgres?

21 March 20252 min di lettura

Pinecone, Qdrant, Weaviate. O semplicemente pgvector. Le soglie reali oltre cui il dedicato vince.

Da quando RAG è entrato nei nostri progetti, la domanda "che vector DB scegliamo?" è ricorrente. Risposta breve: pgvector per la maggior parte dei casi delle PMI italiane.

Le soglie

Per scegliere un vector DB dedicato (Pinecone, Qdrant, Weaviate) almeno una di queste tre cose deve essere vera:

  • Volumi enormi: oltre 10 milioni di vettori. Sotto, pgvector con HNSW gestisce bene.
  • Filtri molto complessi: combinazioni di metadati e similarità che richiedono indici specializzati.
  • Update frequenti: re-embedding di parti del corpus ogni ora. pgvector regge ma con latenza più alta.

Per il resto

pgvector vince per:

  • Operatività: un solo database da gestire, backup, monitoring.
  • Costi: zero infrastruttura aggiuntiva.
  • Join nativi: combinare similarità + filtri SQL classici è banale.
  • Lock-in zero: è Postgres.

HNSW vs IVFFlat in pgvector

pgvector 0.5+ supporta HNSW. È più veloce di IVFFlat su query, costa più memoria e tempo di build dell'indice. Sul nostro caso a 60k vettori: query 1.8 ms (HNSW) vs 6.4 ms (IVFFlat), build 14s vs 2s. Per dataset stabili HNSW è meglio; per dataset che cambiano spesso, IVFFlat è più pragmatico.

Lezioni dal campo

Su 6 progetti RAG nei nostri clienti italiani, 5 stanno su pgvector e 1 su Qdrant (per esigenze di filtri complessi su metadati). Il quasi sempre Postgres tiene anche a 12 mesi di distanza. Non state precoci con il dedicato — risolvete prima il problema, poi infrastrutturalmente.