Vector database: cosa sono e quale scegliere

In una frase

Un vector database è il "magazzino della memoria" dell'AI: archivia i tuoi documenti trasformati in liste di numeri (gli embedding, che ne catturano il significato) e, a ogni domanda, restituisce i più pertinenti per senso, non per parole esatte — in millisecondi, anche su milioni di documenti. È il pezzo di infrastruttura che fa funzionare il RAG.

Il problema che risolve

Un database tradizionale è bravissimo a cercare corrispondenze esatte: "dammi i clienti di Roma". Ma una domanda come "trova i documenti che parlano di questo problema" non è una corrispondenza esatta: è una questione di significato. Se l'utente scrive "cellulare" e il documento dice "smartphone", la ricerca per parole chiave fallisce. Serve un magazzino che sappia cercare per vicinanza di senso: è il vector database.

Lo spazio dei significati (semplificato in 2 dimensioni)

   cane •     • gatto
   cucciolo •                 • fattura
                              • insoluto
   domanda: "animale domestico"
        └─►  cade qui, vicino a cane / gatto / cucciolo

   Il DB restituisce i punti più VICINI = i più simili per significato.

Come ci arrivano i tuoi documenti (l'ingestione)

Prima di poter cercare, i documenti vanno preparati in tre passi:

1. Chunking — si spezzano i documenti in pezzi (chunk) della giusta dimensione. Troppo grandi → recupero impreciso e rumoroso; troppo piccoli → si perde il contesto. Un punto di partenza tipico è intorno ai 500 token a pezzo con un po' di sovrapposizione, ma va tarato sui tuoi dati.
2. Embedding — ogni pezzo viene tradotto nel suo vettore di significato (la lista di numeri).
3. Indicizzazione — i vettori vengono archiviati in un indice ottimizzato per la ricerca per somiglianza.

Come cerca (l'interrogazione)

A ogni domanda, la domanda stessa diventa un embedding e il DB restituisce i top-k vettori più vicini (somiglianza misurata con la distanza coseno).

INGESTIONE (una volta sola)
  documenti  ──►  chunking  ──►  embedding  ──►  [ INDICE VETTORIALE ]

INTERROGAZIONE (a ogni domanda)
  domanda  ──►  embedding  ──►  confronto nell'indice  ──►  i top-k più vicini  ──►  al modello (RAG)

• Velocità sui grandi numeri: su milioni di vettori si usano indici ANN (ricerca approssimata) come HNSW — rinunciano a una briciola di precisione in cambio di una velocità enorme.
• Ricerca ibrida: la ricerca per significato da sola può mancare i match esatti (codici prodotto, nomi propri). Per questo spesso si combina con la ricerca per parole chiave: il meglio dei due mondi.
• Filtri sui metadati: puoi restringere prima o durante la ricerca ("solo documenti del 2025", "solo categoria X").

In che cosa è diverso da un database normale

	DB tradizionale	Vector database
Cosa cerca	corrispondenza esatta	vicinanza di significato
Esempio di query	"città = Roma"	"i 5 testi più simili a questa domanda"
"cellulare" trova "smartphone"?	no	sì
Indice tipico	classico (B-tree)	HNSW (ANN)
Risultato	le righe che combaciano	i top-k più vicini

Quale scegliere: prima i criteri, poi i prodotti

Non esiste "il migliore" in assoluto: dipende dal caso d'uso. Le domande che decidono:

• Hai già un database Postgres? → puoi restare lì con l'estensione pgvector, senza aggiungere un servizio nuovo (per volumi piccoli/medi è spesso la scelta più semplice).
• Stai prototipando o hai pochi dati (meno di ~1 milione di vettori)? → una soluzione embedded leggera basta e avanza.
• Vai in produzione e non vuoi gestire infrastruttura? → un servizio gestito (zero-ops).
• Ti serve ricerca ibrida forte o filtri avanzati? → ci sono open source nati apposta.
• Quanta consistenza immediata ti serve? Molti servizi sono a consistenza eventuale (un dato appena inserito può non essere subito trovato); alcuni offrono consistenza forte.

La fotografia del mercato qui sotto è un'istantanea (giugno 2026) e invecchia in fretta: versioni e prestazioni cambiano a ogni release. Usala come mappa di orientamento, non come verdetto — prima di una scelta tecnica, verifica le fonti aggiornate.

Soluzione	Modello	Punto di forza	Quando sceglierla
Pinecone	gestito (proprietario)	zero-ops, scala senza tuning	produzione, vuoi zero gestione
Weaviate	open source + cloud	ricerca ibrida nativa	hybrid search, flessibilità
Qdrant	open source (Rust)	filtri e free tier	self-host, ricerca filtrata
Chroma	open source, embedded	velocità di sviluppo (< 1M vettori)	prototipi, progetti piccoli
pgvector	estensione di Postgres	nessuna infra nuova, consistenza forte	hai già Postgres

Altri nomi che incontrerai: Milvus, Redis, Elasticsearch/OpenSearch — e molti database generalisti stanno aggiungendo capacità vettoriali.

In sintesi

• Un vector database archivia i documenti come embedding e li cerca per significato, non per parole esatte: è il magazzino su cui poggia il RAG.
• I documenti entrano in tre passi — chunking → embedding → indice; le domande escono come i top-k risultati più vicini.
• Su grandi volumi la ricerca è approssimata (indici ANN / HNSW): un filo di precisione in meno per una velocità enorme. La ricerca ibrida recupera anche i match esatti.
• "Quale scegliere" parte dai criteri (hai già Postgres? che scala? quanta gestione vuoi? che consistenza?), non dal nome di moda.
• Il panorama dei prodotti è volatile: trattalo come orientamento e verifica prima di decidere.

Fonti

• Indici per la ricerca veloce (HNSW): Malkov & Yashunin, Approximate Nearest Neighbor Search using HNSW graphs, 2016 — arXiv:1603.09320
• Recupero per significato (Dense Retrieval): Karpukhin et al., Dense Passage Retrieval for Open-Domain QA, 2020 — arXiv:2004.04906
• Da parole a vettori (word2vec): Mikolov et al., Efficient Estimation of Word Representations in Vector Space, 2013 — arXiv:1301.3781

Materiale informativo a cura di Rayer Group. Non costituisce consulenza tecnica o legale personalizzata: per il caso concreto valutiamo insieme la situazione specifica.