Postgres, pgvector o database vettoriale dedicato? Guida alla scelta
Se la Sua azienda ha già un database Postgres e deve aggiungere ricerca semantica a qualche decina o centinaia di migliaia di documenti, l'estensione pgvector è quasi sempre la scelta più rapida ed economica: niente nuova infrastruttura, niente sincronizzazione tra due sistemi separati. Un database vettoriale dedicato diventa necessario solo oltre certi volumi o requisiti di latenza. Questa guida spiega come orientarsi, con un confronto operativo concreto.
Postgres full-text search: la base che molte aziende hanno già
Prima ancora di parlare di vettori, vale la pena ricordare quanto sia capace la ricerca full-text nativa di Postgres. Con i tipi tsvector e tsquery, un indice GIN e un dizionario linguistico (esiste anche la configurazione italiana), Postgres gestisce stemming, operatori booleani, ricerca per prefisso e ranking con ts_rank in modo efficiente fino a milioni di righe, senza componenti aggiuntivi. Per cataloghi prodotto, archivi di ticket o documentazione interna con terminologia abbastanza prevedibile, questo è spesso sufficiente.
Il limite della full-text search classica è concettuale: cerca parole, non significati. Se un cliente scrive "disdetta" e il documento usa "recesso", oppure se la domanda è formulata in modo molto diverso dal testo originale, la ricerca lessicale può non trovare il passaggio giusto anche se esiste. È proprio questo il problema che la ricerca semantica basata su embedding risolve, come spiegato in ricerca semantica spiegata.
pgvector: portare la ricerca semantica dentro Postgres
pgvector è un'estensione open source che aggiunge a Postgres un tipo di colonna vector(n) e operatori di distanza (coseno, euclidea, prodotto scalare) per confrontare embedding. Il flusso tipico è: genera un embedding per ogni chunk di testo con un modello esterno, salva il vettore in una colonna accanto al testo originale e alle altre colonne relazionali, poi interroga con un operatore come <=> ordinando per distanza crescente. Se non ha chiaro cosa sia esattamente un embedding, questa spiegazione semplice chiarisce il concetto prima di proseguire.
Il vantaggio operativo è enorme: i vettori vivono nella stessa riga dei metadati (autore, data, reparto, permessi), quindi i filtri si scrivono con una normale clausola WHERE, le transazioni restano ACID e il backup è lo stesso backup di sempre. Non serve sincronizzare due database né gestire un secondo sistema di autenticazione e monitoraggio.
Indici ivfflat e HNSW: cosa cambia in pratica
pgvector offre due famiglie di indici approssimati. ivfflat divide lo spazio vettoriale in cluster (liste) e cerca solo nei cluster più vicini: è più leggero da costruire ma richiede di stimare il numero di liste in anticipo e un passaggio di ANALYZE, e la qualità del recall dipende da quanti dati sono già presenti al momento della costruzione dell'indice. HNSW (grafo gerarchico navigabile) offre generalmente un recall migliore senza bisogno di una fase di training dedicata, ma consuma più memoria e il tempo di costruzione dell'indice cresce più velocemente con il numero di righe. Per basi sotto il milione di vettori, HNSW è quasi sempre la scelta più semplice e affidabile.
Ricerca ibrida: full-text e vettori nella stessa query
Il punto in cui pgvector dà il meglio di sé è quando si combina con la full-text search esistente. Una query ibrida calcola sia il punteggio lessicale (ts_rank) sia la distanza vettoriale, poi li combina con una somma pesata o con una tecnica di fusione dei ranking (reciprocal rank fusion). Il risultato cattura sia le corrispondenze esatte (codici prodotto, nomi propri, riferimenti normativi) sia quelle concettuali che solo gli embedding colgono. Abbiamo approfondito il meccanismo in ricerca ibrida: perché BM25 e vettori insieme battono entrambi da soli. Piattaforme come Kopik implementano questa combinazione già pronta all'uso nelle basi di conoscenza che si creano caricando documenti, così da non dover scrivere e mantenere queste query a mano.
Quando un database vettoriale dedicato conviene davvero
Ci sono scenari in cui Postgres con pgvector mostra i suoi limiti e un database vettoriale dedicato (Qdrant, Weaviate, Milvus, o servizi gestiti come Pinecone) diventa la scelta più sensata:
- Volumi oltre alcuni milioni di vettori con aggiornamenti continui, dove gli indici approssimati di Postgres iniziano a degradare in latenza di scrittura.
- Necessità di sharding e distribuzione su più nodi per bilanciare carico e disponibilità a livello globale.
- Filtri su metadata molto complessi e ad alta cardinalità che devono restare performanti insieme alla ricerca vettoriale.
- Pattern di query molto diversi da quelli relazionali, con team che non useranno mai SQL per altro.
- Esigenza di funzionalità specifiche (quantizzazione avanzata, namespace multi-tenant nativi, re-ranking integrato) non disponibili in pgvector.
Se sta valutando queste alternative, il confronto in alternative a Pinecone per piccoli team entra nel dettaglio di pgvector, motori open source e basi di conoscenza ospitate come opzioni intermedie.
Confronto operativo: costi, manutenzione, scalabilità
Postgres + pgvector vs database vettoriale dedicato
| Aspetto | Postgres + pgvector | Database vettoriale dedicato |
|---|---|---|
| Infrastruttura aggiuntiva | Nessuna, usa il Postgres esistente | Nuovo servizio da provisionare e monitorare |
| Scalabilità oltre milioni di vettori | Richiede tuning fine, può degradare | Pensato per questo, scala orizzontalmente |
| Ricerca ibrida full-text + vettori | Nativa nella stessa query SQL | Spesso richiede un secondo sistema di full-text |
| Transazioni e coerenza con i dati relazionali | ACID, stessa riga dei metadati | Eventual consistency in molti prodotti |
| Competenze richieste | SQL e amministrazione Postgres | Nuova API, nuovo modello di dati, nuovo monitoraggio |
| Costi a piccola scala | Marginali, incluso nel costo del database | Piano gestito a parte, spesso minimo mensile |
Sul tema dei costi, se sta confrontando anche soluzioni completamente gestite, l'analisi in costo di un database vettoriale: cosa si paga davvero aiuta a capire quali voci incidono di più oltre al semplice storage.
Checklist per decidere in pratica
- Conti quanti chunk o vettori prevede di avere tra 12 mesi, non solo oggi: sotto 1-2 milioni, pgvector con HNSW è quasi sempre sufficiente.
- Verifichi se le Sue query hanno già bisogno di filtri su metadata complessi oltre al testo: se sì, i filtri SQL di Postgres sono un vantaggio, non uno svantaggio.
- Misuri la latenza accettabile sotto carico reale con EXPLAIN ANALYZE prima di decidere, non basandosi solo su benchmark generici.
- Valuti chi manterrà l'infrastruttura: un secondo database vettoriale significa un secondo sistema da patchare, monitorare e mettere in sicurezza.
- Consideri se la ricerca ibrida (lessicale più semantica) è un requisito: con un database vettoriale puro dovrà reimplementarla separatamente.
Non decida sulla carta
Prima di migrare verso un database vettoriale dedicato, provi pgvector con un campione reale dei Suoi dati e misuri latenza e recall con query vere. Spesso il collo di bottiglia percepito è nel chunking o nel modello di embedding, non nel database: la scelta dello stack, inclusi questi dettagli, è trattata in lo stack RAG open source nel 2026.
Un'ultima nota: se l'obiettivo finale non è gestire un database ma ottenere risposte affidabili sui propri documenti, può avere senso saltare del tutto la scelta infrastrutturale. Caricando i documenti su una base di conoscenza già pronta, l'indicizzazione ibrida, il chunking e la scalabilità sono gestiti a monte, e resta solo da interrogare la base via web, API o server MCP.
Provi la ricerca ibrida senza gestire un database
Crei una base di conoscenza gratuita su Kopik caricando i Suoi documenti: indicizzazione full-text e semantica è già configurata, e può interrogarla dal sito, via API con chiavi dedicate o da client MCP come Claude e Cursor.
Domande frequenti
Pgvector sostituisce completamente un database vettoriale dedicato?
Per la maggior parte dei casi d'uso fino a qualche milione di vettori, sì: offre ricerca semantica, indici approssimati (ivfflat, HNSW) e si integra con i dati relazionali già presenti in Postgres. Serve un database dedicato solo oltre certi volumi o con requisiti specifici di distribuzione.
Pgvector rallenta le query normali di Postgres?
No, pgvector aggiunge un tipo di dato e operatori nuovi senza modificare il comportamento delle query esistenti. L'unico impatto è lo spazio occupato dagli indici vettoriali e il tempo di costruzione, che va monitorato come per qualsiasi altro indice.
Quanti vettori posso gestire con pgvector prima di avere problemi?
Non esiste un limite rigido, ma in pratica con HNSW ben configurato molte installazioni restano performanti fino a diversi milioni di righe. Oltre quella soglia, latenza di scrittura e tempi di costruzione dell'indice iniziano a richiedere più attenzione o un'architettura distribuita.
Meglio HNSW o ivfflat con pgvector?
HNSW offre generalmente un recall migliore senza bisogno di una fase di training preliminare ed è la scelta più semplice per la maggior parte dei progetti. ivfflat consuma meno memoria ma richiede di stimare in anticipo il numero di cluster e un passaggio di ANALYZE sui dati.
Serve sempre la ricerca ibrida o basta il vettoriale puro?
Dipende dal contenuto: per testi con terminologia precisa (codici, riferimenti normativi, nomi propri) la componente lessicale cattura corrispondenze esatte che il solo vettoriale può perdere. Combinare i due approcci riduce sia i falsi negativi sia le risposte fuori contesto.
Conviene iniziare con pgvector e migrare dopo verso un database dedicato?
Sì, è spesso la strategia più prudente: pgvector ha un costo di adozione basso e permette di validare il caso d'uso. Se i volumi o i requisiti di latenza crescono davvero, la migrazione verso un database vettoriale dedicato resta possibile senza aver sprecato tempo su un'infrastruttura sovradimensionata fin dall'inizio.
Riceva la newsletter di Kopik
Nuove basi di conoscenza, guide sul RAG e novità del prodotto. Un'email ogni una o due settimane, disiscrizione con un clic.
Iscrivendosi accetta di ricevere la nostra newsletter. Il Suo indirizzo non viene mai condiviso.