Che cos’è un database vettoriale? (Guida 2026)

Un database vettoriale memorizza i dati sotto forma di liste di numeri chiamate embedding, quindi individua le voci più vicine in termini di significato rispetto alla richiesta effettuata. Questa è l'idea centrale. Mentre un database tradizionale esegue corrispondenze esatte di valori («trova le righe in cui country = 'Francia'»), un database vettoriale confronta concetti: «trova i paragrafi che trattano lo stesso argomento della domanda posta», anche quando non vi è alcuna sovrapposizione lessicale.

Questa capacità rappresenta il motore di quasi tutte le funzionalità AI serie rilasciate nel 2026: chatbot in grado di citare i tuoi documenti, ricerca semantica, sistemi di raccomandazione e, in particolare, la generazione con recupero aumentato (RAG). Questa guida spiega cos'è effettivamente un database vettoriale, come funzionano gli embedding e la ricerca per similarità a livello tecnico, le sei soluzioni più comuni valutate dai team e — altrettanto importante — quando non ne hai affatto bisogno.

Cos'è realmente un database vettoriale

Per un computer, la frase «il gatto sedeva sul tappeto» è un testo privo di significato. Un modello di embedding — una rete neurale addestrata appositamente — converte tale frase in una lista di numeri di lunghezza fissa, spesso 768, 1.024 o 1.536. Ogni numero cattura una qualche dimensione appresa del significato. Il risultato è un punto nello spazio ad alta dimensionalità, e la proprietà utile è questa: frasi con significati simili si posizionano vicine tra loro, mentre frasi non correlate risultano distanti. «Il gattino riposava sul tappeto» finisce vicino alla nostra frase sul gatto, pur avendo quasi nessuna parola in comune.

Un database vettoriale è progettato appositamente per memorizzare milioni o miliardi di questi punti e rispondere rapidamente a una sola domanda: quali vettori memorizzati sono più vicini a questo vettore di query? Integra l'indice che rende efficiente tale ricerca, il filtraggio basato sui metadati (per poter dire, ad esempio, «risultati più vicini, ma solo del 2025») e l'infrastruttura di archiviazione e scalabilità necessaria per mantenerlo operativo. Se desideri un contesto più ampio su come questi componenti si inseriscono nei sistemi AI, la nostra guida introduttiva all'apprendimento automatico tratta i modelli di embedding che alimentano inizialmente il database.

Embedding e similarità, in breve

«Più vicino» richiede una definizione. La metrica più comune per il testo è la similarità coseno, che misura l'angolo tra due vettori ignorandone la lunghezza. Varia da -1 (significato opposto) a 1 (direzione identica); poiché la maggior parte dei moderni modelli di embedding produce vettori normalizzati di lunghezza unitaria, la similarità coseno risulta matematicamente equivalente al più rapido prodotto scalare. La distanza euclidea è l'altra opzione che incontrerai, utile quando la grandezza stessa porta informazioni significative. Per applicazioni tipiche di RAG e ricerca semantica, la similarità coseno è la scelta predefinita più ragionevole ed è quella utilizzata di default dalla maggior parte dei database.

Come funziona la ricerca per similarità su larga scala

Ecco l'ostacolo. Confrontare la query con ogni vettore memorizzato — una scansione esaustiva — fornisce risultati perfetti, ma diventa insostenibile sotto carico. Con 10 milioni di vettori, verificare ciascuno di essi per ogni query è troppo lento per un'applicazione interattiva. I database vettoriali usano quindi la ricerca approssimata dei k vicini più prossimi (ANN) : accettano un tasso di accuratezza del 95–99% in cambio di velocità superiori di diversi ordini di grandezza.

Il metodo ANN dominante nel 2026 è HNSW (Hierarchical Navigable Small World), introdotto da Yury Malkov e Dmitry Yashunin in un articolo del 2016. Costruisce un grafo stratificato — immagina una struttura tipo skip list incrociata con una rete stradale. Lo strato superiore è sparso, con pochi nodi collegati da «autostrade» a lunga distanza; ogni strato sottostante aggiunge più nodi e strade locali più brevi, mentre lo strato inferiore contiene tutti i vettori. Una ricerca inizia dallo strato superiore, compie salti lunghi per entrare nella zona corretta, quindi scende attraverso strati progressivamente più dettagliati per individuare con precisione i vettori più vicini. Per dati che rientrano nella memoria, HNSW garantisce costantemente il miglior compromesso tra recall e latenza, motivo per cui quasi tutti i motori qui elencati lo implementano.

L'altra metà della storia dello scaling è quantizzazione — la compressione dei vettori per farne entrare di più nella RAM. Le tecniche spaziano dalla quantizzazione scalare e prodotto fino a metodi estremi a 1 bit. L'implementazione RaBitQ di Milvus, ad esempio, riporta una riduzione dell'uso di memoria pari a circa il 72% (abbinata a un passaggio di affinamento SQ8), mantenendo il tasso di richiamo vicino al 95%. È proprio questa compressione a rendere economicamente sostenibile la ricerca su scala miliardaria.

I principali database vettoriali del 2026

Il mercato si suddivide in tre categorie: servizi completamente gestiti, motori open source auto-hostabili e l'estensione per Postgres che, quasi in silenzio, ha conquistato una grossa fetta del segmento basso. Ecco come si confrontano le principali opzioni, con dettagli verificati su fonti aggiornate alla metà del 2026.

Gestito: Pinecone

Pinecone è l'opzione «paga qualcun altro perché lo gestisca». La sua architettura serverless ti permette di memorizzare miliardi di vettori senza dover provisionare server, e vieni fatturato in base alle unità di lettura, scrittura e archiviazione anziché su nodi fissi — soluzione particolarmente adatta al traffico RAG intermittente, che cala drasticamente durante la notte. Nel 2026 i prezzi partono da un piano gratuito Starter, passano per un piano Builder a tariffa fissa di 20 dollari/mese, arrivano al piano Standard (minimo circa 50 dollari/mese) e all’Enterprise (minimo circa 500 dollari/mese), con un costo serverless approssimativo di 4 dollari per milione di unità di scrittura, 16 dollari per milione di unità di lettura e 0,33 dollari/GB/mese per l’archiviazione. La piattaforma si è evoluta oltre la semplice memorizzazione, includendo Pinecone Inference (embedding e reranking ospitati) e Assistant per applicazioni di tipo agente, mentre Bring Your Own Cloud è ora in anteprima pubblica per i clienti Enterprise.

Open source: Qdrant, Weaviate, Milvus, Chroma

Se preferisci possedere l'intero stack, il campo open source è molto solido. QdrantQdrant, scritto in Rust, è il favorito in termini di prestazioni — veloce, sicuro dal punto di vista della memoria, con ricche opzioni di quantizzazione e un pacchetto di funzionalità enterprise rilasciato nel 2026 (indicizzazione GPU, cluster Multi-AZ, audit log implementati su Qdrant Cloud nell'aprile 2026). WeaviateWeaviate, scritto in Go, guida nel campo della ricerca ibrida: combina ricerca per parole chiave (BM25) e ricerca vettoriale con filtri sui metadati in un’unica query, una caratteristica davvero utile quando contano sia i termini esatti sia il significato approssimativo. MilvusMilvus, progetto in Go e C++ sviluppato da Zilliz e progetto laureato presso LF AI & Data, è la scelta ideale per l’estremo alto della gamma — la sua architettura è pensata per scale miliardarie e la sua quantizzazione RaBitQ ne rende accessibile il costo. Chroma Chroma si colloca all’opposto dello spettro: gira in-process, ti fornisce da zero a un indice funzionante in pochi minuti ed è ideale per la fase di prototipazione, anche se il suo punto di forza rimane intorno ai 5–10 milioni di vettori per nodo.

I dati di throughput rilevati a metà 2026 offrono una prospettiva comparativa: Qdrant e Weaviate raggiungono comunemente decine di migliaia di query al secondo, mentre Milvus può superare i 100.000 QPS su larga scala — tuttavia i valori reali dipendono fortemente dalle dimensioni dei vettori, dall’hardware impiegato e dagli obiettivi di recall, quindi è essenziale eseguire benchmark sui propri dati prima di fidarsi di qualsiasi cifra isolata.

L’approccio Postgres: pgvector

pgvector è la voce più importante di questa lista per un semplice motivo: non è affatto un database separato, bensì un’estensione che aggiunge colonne vettoriali e indicizzazione ANN a PostgreSQL. I tuoi embedding risiedono nella stessa tabella dei dati relazionali, interrogabili con una singola istruzione SQL e in una sola transazione. La versione 0.8 ha chiuso gran parte delle lacune residue, introducendo scansioni iterative degli indici che risolvono il vecchio problema del sovrafiltraggio, per cui una clausola WHERE poteva privare la ricerca vettoriale di risultati. Supporta sia indici HNSW che IVFFlat ed è utilizzato in produzione da grandi team. Il vantaggio operativo è chiaro: un solo sistema da gestire, backuppare e monitorare, invece di due.

Quando hai davvero bisogno di un database vettoriale (e quando non ce n'è bisogno)

Questo è il quesito che troppe squadre trascurano. Un database vettoriale dedicato è vera infrastruttura — un altro servizio da distribuire, proteggere, scalare e pagare. Dovresti sceglierne uno quando ne hai effettivamente bisogno per le sue caratteristiche distintive.

Probabilmente fare hai bisogno di un motore dedicato quando superi i 5–10 milioni di vettori, richiedi una latenza p99 inferiore ai 10 ms con elevato volume di query, dipendi da avanzate funzionalità di ricerca ibrida o stai costruendo un prodotto multi-tenant dove contano isolamento e scalabilità orizzontale. A quella scala i sistemi specializzati si distinguono nettamente.

Probabilmente non quando si gestiscono meno di circa un milione di vettori, si utilizza già PostgreSQL e i requisiti di latenza sono nell’ordine delle decine di millisecondi anziché di pochi millisecondi. Il consenso del 2026 è inequivocabile: al di sotto di circa 10 milioni di vettori, pgvector eguaglia o supera le soluzioni dedicate sulle metriche rilevanti per la maggior parte delle applicazioni, e si distingue nettamente per la semplicità operativa. Partite da qui e passate a un database specializzato solo quando incontrerete un collo di bottiglia misurabile. Lo stesso ragionamento vale per una scelta architetturale più ampia: prima di implementare qualsiasi stack di retrieval, vale la pena valutare il fine-tuning rispetto al RAG per verificare se il retrieval sia effettivamente lo strumento giusto per il vostro problema.

Come i database vettoriali abilitano il RAG

Il motivo per cui tutto ciò è rilevante per la maggior parte degli sviluppatori è il retrieval-augmented generation (RAG). Un modello linguistico di grandi dimensioni (LLM) conosce soltanto ciò su cui è stato addestrato e non ha accesso ai vostri documenti interni, ai ticket della settimana scorsa o al vostro catalogo prodotti. Il RAG risolve questo limite: si trasformano preliminarmente i documenti in embedding vettoriali e li si memorizzano in un database vettoriale; in fase di query, si converte la domanda dell’utente in un embedding vettoriale, si recuperano i frammenti più simili e li si fornisce al modello come contesto aggiuntivo. L’LLM genera quindi risposte basate su materiale reale, aggiornato e ancorato a fonti attendibili, anziché affidarsi a ipotesi.

Il database vettoriale costituisce il livello di retrieval in questo ciclo e la sua qualità definisce un tetto massimo per l’intero sistema: un retrieval scadente produce risposte scadenti, indipendentemente dall’eccellenza del modello. Se desiderate vedere l’intero ciclo integrato end-to-end, la nostra guida pratica sulla costruzione di una pipeline RAG posiziona correttamente il database accanto alle fasi di chunking, embedding e generazione.

Domande frequenti

Un database vettoriale è la stessa cosa di un database tradizionale?

No. Un database relazionale o documentale è progettato per eseguire query esatte e strutturate — ad esempio confronti di ID, intervalli o valori di campo. Un database vettoriale, invece, è progettato per individuare elementi in base alla similarità semantica, sfruttando embedding ad alta dimensionalità. Molti sistemi, come pgvector, integrano oggi la ricerca vettoriale in un database tradizionale, offrendo entrambe le funzionalità in un’unica soluzione.

Ho bisogno di un database vettoriale per il RAG?

Hai bisogno di ricerca vettoriale per il RAG, ma non necessariamente un database vettoriale dedicato. Per corpora di piccole e medie dimensioni, pgvector integrato nel vostro PostgreSQL esistente gestisce efficacemente il retrieval. Un motore autonomo come Pinecone o Qdrant giustifica il proprio costo solo quando si superano i milioni di documenti o si richiede una latenza estremamente bassa.

Cos’è HNSW e perché è importante?

HNSW (Hierarchical Navigable Small World) è l’indice approssimato per la ricerca dei k vicini più prossimi più diffuso. Costruisce un grafo gerarchico che consente alla ricerca di ‘saltare’ rapidamente nella regione corretta dello spazio vettoriale e quindi affinare il risultato, restituendo in millisecondi risultati quasi perfetti. È fondamentale perché rende la ricerca per similarità sufficientemente veloce da essere utilizzata in tempo reale.

La similarità coseno è migliore della distanza euclidea?

Per gli embedding testuali, la similarità coseno è generalmente la scelta predefinita più appropriata, poiché confronta la direzione (il significato) anziché la grandezza. Quando gli embedding sono normalizzati a lunghezza unitaria — come avviene nella maggior parte degli attuali modelli — similarità coseno, prodotto scalare e distanza euclidea producono identici ordinamenti dei risultati; la scelta dipende quindi spesso dall’efficienza computazionale.

Quale database vettoriale è il migliore per i principianti?

Chroma e pgvector sono i punti di partenza più intuitivi. Chroma gira in-process con quasi nessuna configurazione, ed è ideale per un primo prototipo. pgvector è invece la scelta migliore se già utilizzate PostgreSQL, poiché aggiunge la ricerca vettoriale senza introdurre un nuovo sistema da imparare.

Quanto costano i database vettoriali nel 2026?

I motori open source — Qdrant, Weaviate, Milvus, Chroma, pgvector — sono gratuiti per l’auto-hosting; pagherete soltanto per l’hardware. I piani gestiti partono da zero costi e aumentano progressivamente (il piano Builder di Pinecone costa una tariffa fissa di 20 dollari/mese, quello Standard circa 50 dollari/mese, mentre l’Enterprise si attesta intorno ai 500 dollari/mese), fino a contratti enterprise per carichi produttivi, dove la fatturazione basata sull’utilizzo può variare ampiamente in base al volume di letture e scritture.

Posso usare un database vettoriale per immagini o audio, non solo per testo?

Sì. Qualsiasi tipo di dato codificabile tramite un modello di embedding — immagini, audio, video, codice — diventa un vettore che è possibile memorizzare e ricercare per similarità. Il database non si interessa di cosa rappresentino i vettori; esegue soltanto i calcoli. Il retrieval multimodale (ricerca congiunta su testo e immagini) è sempre più comune nel 2026.

Conclusione

Un database vettoriale è la componente dello stack AI che recupera informazioni in base al significato; nel 2026 non è più una tecnologia esotica, ma un elemento standard per RAG, ricerca semantica e raccomandazioni. Il consiglio sincero è evitare l’eccessiva complessità architetturale. Se già utilizzate PostgreSQL e gestite meno di circa 10 milioni di vettori, partite da pgvector: probabilmente non avrete mai bisogno di altro. Quando lo supererete — miliardi di vettori, latenza nell’ordine di pochi millisecondi, ricerca ibrida intensiva — i specialisti open source (Qdrant, Weaviate, Milvus) e il servizio completamente gestito Pinecone sono tutti maturi, ben finanziati e pronti all’uso. Scegliete in base alla vostra scala reale e alle vostre esigenze operative, non al clamore mediatico, e fate benchmark sui vostri dati prima di impegnarvi.