Database vettoriale: quale scegliere e quando evitarlo

Negli ultimi due anni la frase me la sono sentita dire decine di volte: "ci serve un database vettoriale". Quasi sempre arriva prima della domanda vera, che sarebbe: quale problema stiamo cercando di risolvere.

Nella maggior parte dei progetti che ho seguito, la risposta onesta è che un database vettoriale dedicato non serviva. Serviva una ricerca semantica fatta bene sopra il database che l'azienda aveva già. In altri casi serviva eccome, e sceglierlo male è costato settimane.

Qui ti spiego cos'è, come funziona davvero, cosa cambia quando lo usi dentro un sistema RAG, e soprattutto come capire in quale dei due casi sei. Senza vendere niente: tutta la prima pagina di Google su questo tema è documentazione di chi il prodotto lo vende.

Che cos'è un database vettoriale

Un database tradizionale cerca corrispondenze. Gli chiedi le righe dove il campo vale "fattura" e ti dà quelle, esattamente quelle. Se il documento dice "nota di debito", non lo trovi.

Un database vettoriale cerca somiglianza di significato. Ogni pezzo di testo viene trasformato da un modello in una lista di numeri, il vettore o embedding, che ne rappresenta il senso in uno spazio a molte dimensioni. Testi che parlano della stessa cosa finiscono vicini in quello spazio, anche se non condividono una parola.

È tutto qui il trucco, ed è anche il suo limite: il vettore cattura il significato, non i fatti. Un database vettoriale non sa che una fattura è scaduta. Sa che quel paragrafo assomiglia alla tua domanda.

Come funziona un database vettoriale

Il ciclo, semplificando ma senza barare, è questo.

1. Trasformazione. Ogni documento viene spezzato in pezzi e ogni pezzo passa a un modello di embedding che restituisce il vettore.
2. Indicizzazione. I vettori finiscono in un indice costruito per trovare i vicini in fretta. Confrontare la domanda con tutti i vettori uno per uno funziona finché sono pochi; oltre, si usano indici approssimati che scambiano un pizzico di precisione con molta velocità.
3. Ricerca. La domanda dell'utente diventa a sua volta un vettore, e il database restituisce i pezzi più vicini.
4. Filtri. Nella pratica quasi nessuna ricerca è puramente semantica: vuoi i pezzi più simili ma solo di quel cliente, solo dell'ultimo anno. La qualità con cui un database combina filtri e similarità è la differenza vera tra un prodotto e l'altro, molto più della velocità dichiarata nei benchmark.

Che cos'è il sistema RAG e come si costruisce

RAG sta per generazione aumentata dal recupero, e in pratica significa una cosa sola: prima di rispondere, il modello va a cercarsi i documenti giusti e se li mette davanti.

Serve perché un modello linguistico non conosce i tuoi dati, e quando non sa inventa. Il RAG non lo rende più intelligente: gli mette in mano i fogli giusti prima di farlo parlare.

Costruirne uno sono cinque passaggi, e il punto interessante è che il database è quello facile.

1. Ingestione. Recuperare i documenti e ridurli a testo pulito. Se hai PDF scansionati o Excel con celle unite, è qui che si perde metà del tempo del progetto.
2. Chunking. Spezzare i testi in pezzi. È la decisione che determina la qualità finale più di ogni altra: pezzi troppo grandi diluiscono il significato, troppo piccoli perdono il contesto. Tagliare seguendo la struttura del documento, per sezione o per paragrafo, funziona quasi sempre meglio che tagliare a lunghezza fissa.
3. Embedding e indicizzazione. Qui entra il database. Se lavori in italiano, verifica che il modello di embedding sia davvero multilingua: è l'errore silenzioso che ho visto più spesso, perché il sistema funziona, restituisce risultati, solo che sono mediocri e nessuno se ne accorge.
4. Recupero e riordino. Prendere i candidati e riordinarli con un reranker prima di passarli al modello. È il singolo intervento che, nella mia esperienza, migliora di più le risposte a parità di tutto il resto.
5. Generazione. Passare i pezzi al modello con l'istruzione di rispondere solo su quelli e di citare la fonte. Senza questo vincolo il RAG serve a poco: il modello usa i documenti come suggerimento e continua a improvvisare.

Manca un sesto passaggio che quasi nessuno fa e che invece è decisivo: valutare. Prepara trenta domande reali con la risposta attesa e misura quante volte il pezzo giusto compare tra i recuperati. Senza quel numero non stai migliorando il sistema, stai cambiando cose a caso.

Quando il database vettoriale non ti serve

Se usi già PostgreSQL, hai un'opzione che quasi nessuno ti proporrà: pgvector, l'estensione che aggiunge il tipo vettore e la ricerca per similarità al database che hai già in produzione.

I vantaggi sono concreti e poco romantici. Un solo sistema da gestire, da mettere in backup e da monitorare. I filtri sui metadati sono normale SQL, quindi combini similarità e condizioni senza contorsioni. E soprattutto i tuoi dati restano in un posto solo: niente sincronizzazione tra il database di verità e l'indice vettoriale, che è una delle fonti di bug più fastidiose da diagnosticare, perché il sistema non si rompe, semplicemente risponde con roba vecchia.

Per la base documentale di una PMI, cioè manuali, procedure, cataloghi e storico delle richieste, questa strada regge benissimo. Chi ti dice il contrario di solito ha un prodotto da vendere.

Quando invece serve davvero

Ci sono situazioni in cui il database dedicato se lo merita, e sono riconoscibili.

• Volumi alti. Quando i vettori diventano davvero tanti, gli indici specializzati e la loro gestione della memoria fanno la differenza.
• Scritture continue. Se i documenti cambiano di continuo e l'indice deve restare aggiornato in tempo reale, i motori dedicati gestiscono meglio l'aggiornamento incrementale.
• Multi-tenant serio. Tanti clienti, ognuno con i propri dati da tenere rigorosamente separati e da poter cancellare in blocco.
• Ricerca ibrida. Quando ti serve combinare in modo fine la ricerca per parole chiave e quella semantica, con pesi e reranking integrati.

Le opzioni serie sono diverse e vanno scelte per come lavori, non per la classifica del momento. Qdrant è la scelta più equilibrata se vuoi ospitarlo tu e ti servono filtri solidi. Chroma è ottimo per prototipare in fretta, meno per reggere la produzione. Pinecone toglie di mezzo la gestione ma è un servizio gestito, con quel che comporta in termini di dipendenza e di dove finiscono i dati. Milvus e Weaviate arrivano dove gli altri si fermano per scala e funzionalità, al prezzo di una complessità operativa vera. E se hai già Elasticsearch o OpenSearch in casa, guarda lì prima di aggiungere un pezzo nuovo all'infrastruttura.

Gli errori che trovo più spesso

• Scegliere il database prima di avere i dati. Il vincolo vero non è mai il motore: è la qualità dei documenti di partenza.
• Nessun reranking. Si passano al modello i primi risultati così come escono, e la risposta peggiora senza che nessuno capisca perché.
• Chunk a lunghezza fissa. Veloce da implementare, taglia le frasi a metà, rovina il recupero.
• Metadati assenti. Senza data, fonte e proprietario su ogni pezzo non puoi filtrare, non puoi citare e non puoi cancellare i dati di un cliente quando te lo chiede.
• Zero valutazione. Il punto già detto, ripetuto perché è quello che separa i progetti che migliorano da quelli che restano una demo.

Sui costi non ti do numeri, perché dipendono troppo da volume e architettura: le voci da mettere a preventivo sono la generazione degli embedding, che si paga a consumo e va rifatta ogni volta che cambi modello, lo spazio di archiviazione e soprattutto la memoria del server, perché gli indici vettoriali vivono in RAM ed è lì che il conto sale.

Leggi anche

• MCP 2026: cos'è, come funziona e creare un server
• Server MCP in azienda: cosa ho imparato costruendone uno
• Top 20 repository GitHub per LLM
• Installare n8n su server: guida, costi e manutenzione

Come deciderei io, al posto tuo

Parti dalla domanda a cui il sistema deve rispondere, non dalla tecnologia. Prendi trenta domande vere dei tuoi utenti, mettile per iscritto con la risposta corretta, e costruisci la versione più stupida possibile del sistema sopra il database che hai già. Misura.

Se i risultati reggono, hai finito e hai risparmiato un pezzo di infrastruttura. Se non reggono, adesso sai esattamente dove si rompe, e la scelta del database vettoriale diventa una decisione informata invece di un acquisto di fiducia.

Se vuoi che guardi il tuo caso e ti dica quale delle due strade ha senso, compila il modulo di contatto oppure scrivimi a info@cosimo.dev. Ti rispondo io, e se la risposta è che non ti serve te lo dico.