Database vettoriali vs tradizionali: differenze e usi nel 2026

I database vettoriali sono sistemi di archiviazione progettati per memorizzare e interrogare dati sotto forma di vettori ad alta dimensionalità, mentre i database tradizionali (relazionali, SQL) organizzano le informazioni in tabelle strutturate con schemi rigidi. La differenza chiave sta nel tipo di ricerca supportata: i database SQL eseguono query esatte su dati strutturati, i database vettoriali trovano elementi semanticamente simili tramite calcolo di distanza in spazi multidimensionali. La guida copre anche il terzo confronto che chi progetta un sistema AI si trova davanti: database vettoriale vs database a grafo, e grafo della conoscenza vs database vettoriale nel pattern GraphRAG. Con l’ascesa dell’intelligenza artificiale generativa e dei Large Language Models, i database vettoriali come Qdrant sono diventati infrastruttura fondamentale per pipeline RAG e ricerca semantica. Nel 2026, però, il confine si è fatto più sottile: i principali motori relazionali hanno integrato indici e tipi di dato vettoriali nativi, e la domanda non è più «quale dei due» ma «dove mettere il confine».

In questo articolo scoprirai:

• Come funzionano database SQL e database vettoriali, e come funziona davvero la ricerca per somiglianza: coseno, prodotto scalare, distanza euclidea.
• Un confronto diretto tra database vettoriali e tradizionali su scalabilità, schema, costi e casi d’uso.
• Le differenze tra database vettoriale, database a grafo e grafo della conoscenza, e quando combinarli con GraphRAG.
• Cosa è cambiato nel 2026: i vettori nativi in PostgreSQL, Oracle AI Database 26ai e SQL Server 2025.
• Quando bastano pgvector o un’architettura ibrida, quando serve Qdrant, e quanto costa davvero un database vettoriale in produzione.

Capire i Database SQL (i “database tradizionali”)

Un database SQL è un sistema relazionale che organizza i dati in tabelle con righe e colonne tipizzate, interrogabili tramite il linguaggio Structured Query Language. Il modello relazionale fu formalizzato da Edgar F. Codd in un celebre paper del 1970, A Relational Model of Data for Large Shared Data Banks, e da allora domina la gestione dei dati aziendali. La struttura rigida e ben definita facilita l’organizzazione delle informazioni e rende il recupero particolarmente efficiente attraverso query precise, adatte a una vasta gamma di applicazioni aziendali e informatiche.

La famiglia si è nel frattempo diversificata: accanto ai motori transazionali classici (PostgreSQL, MySQL, SQL Server) sono cresciuti i motori analitici colonnari orientati alle query OLAP, dove l’esecuzione vettorizzata delle operazioni porta guadagni di ordini di grandezza. È il caso di DuckDB e della sua architettura ottimizzata: un promemoria utile del fatto che “SQL” non significa automaticamente “lento sui grandi volumi”.

Vantaggi dei Database SQL

1. Integrità dei dati e garanzie ACID: vincoli di chiave, tipi espliciti e transazioni atomiche impediscono che un dato incoerente entri nel sistema. È la ragione per cui ordini, pagamenti e anagrafiche stanno ancora su un relazionale: la correttezza è imposta dal motore, non dal codice applicativo.
2. Interrogazione Complessa: Grazie al linguaggio SQL, è possibile eseguire query molto complesse che includono JOIN, sottointerrogazioni, aggregati e funzioni di ordinamento. Questa capacità rende i database SQL estremamente versatili e capaci di gestire complesse analisi dati, reportistica e operazioni di business intelligence.
3. Ecosistema e competenze diffuse: backup, replica, controllo degli accessi, audit e strumenti di governance sono maturi da decenni. In un progetto aziendale questo si traduce in minori costi operativi e in un rischio di lock-in più basso rispetto a servizi vettoriali proprietari.

Limitazioni dei Database SQL

1. Sfide di Scalabilità: Nonostante l’efficienza e la robustezza, i database SQL tradizionali possono incontrare limitazioni nella scalabilità, specialmente in orizzontale. Mentre la scalabilità verticale (incremento delle risorse nel singolo server) è generalmente gestibile, espandere l’architettura su più server (scalabilità orizzontale) può presentare complessità significative. Questo aspetto è particolarmente critico in applicazioni che devono gestire volumi di dati in crescita esponenziale o che richiedono alte prestazioni in termini di accesso ai dati.
2. Schema Rigido: I database SQL richiedono la definizione di uno schema prima che i dati possano essere immagazzinati. Questo schema deve definire con precisione come i dati sono organizzati, includendo tipi di dati, tabelle e relazioni. Sebbene questo approccio garantisca ordine e coerenza, può anche limitare la flessibilità. Adattarsi a modifiche sostanziali nella struttura dei dati, come l’aggiunta di nuovi campi o la modifica di relazioni, può risultare complicato e richiedere migrazioni dati complesse.
3. Assenza di semantica nativa: una query SQL classica trova ciò che corrisponde, non ciò che significa la stessa cosa. La ricerca full-text con indici testuali attenua il problema ma resta legata alle parole, non ai concetti: è esattamente il vuoto che gli embeddings riempiono.

Esplorare i Database Vettoriali

Un database vettoriale è un sistema ottimizzato per memorizzare e interrogare dati sotto forma di vettori numerici ad alta dimensionalità, tipicamente prodotti da modelli di intelligenza artificiale. A differenza dei tradizionali database basati su SQL, i database vettoriali utilizzano un’architettura pensata per gestire dati rappresentati come array numerici, concetti matematici fondati sull’algebra lineare applicata al machine learning. Questa categoria di sistemi è emersa come risposta alle esigenze delle tecnologie emergenti nei settori dell’intelligenza artificiale e del machine learning.

Cos’è un Database Vettoriale

Un database vettoriale è specializzato nella memorizzazione e nell’interrogazione di dati rappresentati come vettori, cioè array di numeri che descrivono le caratteristiche di oggetti in spazi ad alta dimensionalità. Questi vettori vengono generati da modelli di intelligenza artificiale attraverso un processo chiamato embedding: ogni parola, frase, immagine o documento viene trasformato in una sequenza numerica che ne cattura il significato semantico. Per capire come si producono e si usano queste rappresentazioni conviene partire dalla guida agli embeddings, che copre anche le famiglie di modelli oggi più diffuse (dai modelli di embedding di OpenAI e Cohere alle alternative open come BGE ed E5) e le tecniche di riduzione della dimensionalità. Questa peculiarità rende i database vettoriali strumenti indispensabili in campi come la visione artificiale, il riconoscimento del parlato e il processamento automatico del linguaggio, dove è fondamentale poter comparare elementi complessi quali immagini, tracce audio e testi per trovare correlazioni o somiglianze.

Come Funziona la Ricerca per Somiglianza: Coseno, Prodotto Scalare, Distanza Euclidea

Cercare in un database vettoriale significa calcolare una misura di distanza tra il vettore della query e quelli archiviati, poi restituire i più vicini. Le metriche usate in pratica sono tre. La similarità del coseno misura l’angolo tra due vettori e ignora la loro lunghezza: è la scelta abituale per il testo, dove conta la direzione semantica e non l’intensità. Il prodotto scalare tiene conto anche della magnitudine ed è più veloce da calcolare; su vettori normalizzati produce lo stesso ordinamento del coseno. La distanza euclidea (L2) misura la separazione geometrica nello spazio ed è comune sulle rappresentazioni di immagini e su feature numeriche non normalizzate.

Il punto pratico che sfugge più spesso: la metrica non si sceglie a gusto, si eredita dal modello di embedding. Ogni modello viene addestrato con un obiettivo che presuppone una specifica misura di similarità, e usarne un’altra in fase di query degrada il recall senza produrre alcun errore visibile: il sistema continua a rispondere, solo con i documenti sbagliati. È lo stesso meccanismo per cui la ricerca per coseno restituisce la pagina vicina invece di quella giusta: la somiglianza geometrica non è la pertinenza, e confonderle è l’errore più comune di chi mette in produzione il primo indice. Prima di configurare l’indice, verificate quale metrica raccomanda la scheda del modello che state usando.

Caratteristiche Principali dei Database Vettoriali

1. Ricerca di Somiglianza Efficiente: I database vettoriali sono progettati per eseguire ricerche tra vettori “vicini” in modo estremamente efficiente. Utilizzano algoritmi di ricerca approssimata del vicino più prossimo (ANN) come HNSW (Hierarchical Navigable Small World) o IVF (Inverted File Index) per identificare rapidamente i vettori più simili a quello dato in input. Accanto a HNSW, oggi standard de facto in memoria, si sono affermati indici pensati per l’archiviazione su disco (famiglia DiskANN), che riducono il costo per milione di vettori quando il dataset non sta in RAM.
2. Flessibilità dello Schema: A differenza dei database SQL, che richiedono la definizione di uno schema rigido e predefinito, i database vettoriali offrono una maggiore flessibilità: non sono vincolati da uno schema fisso e permettono di aggiungere o modificare gli attributi associati a ogni elemento senza ristrutturare l’intero database. Attenzione però al confine di questa flessibilità: riguarda i metadati che accompagnano i vettori (il payload), non i vettori stessi. Dimensione del vettore e metrica di distanza si fissano alla creazione della collezione, e cambiarle significa ricrearla da zero.
3. Prestazioni su Dati ad Alta Dimensionalità: questi sistemi gestiscono volumi enormi di vettori con centinaia o migliaia di dimensioni mantenendo latenze compatibili con l’uso interattivo, e lo fanno rinunciando alla ricerca esatta in favore di quella approssimata: al crescere delle dimensioni la scansione esatta diventa impraticabile, quindi si accetta di perdere qualche risultato in cambio della velocità. L’architettura pensata intorno a questo compromesso è descritta nel paper Milvus di Wang et al. (2021).

I casi d’uso dei database vettoriali: dalla ricerca semantica al RAG

I casi d’uso concreti dei database vettoriali seguono tutti lo stesso schema: un modello converte dati grezzi in embedding, il database li indicizza, la query restituisce i più vicini nello spazio semantico. Le applicazioni più diffuse sono la ricerca semantica (trovare documenti per significato, non per parole chiave esatte), le pipeline RAG con LLM (recuperare i chunk rilevanti da passare al modello generativo), i sistemi di raccomandazione (prodotti, contenuti o utenti simili per comportamento), il riconoscimento di immagini e la deduplicazione di record vicini nello spazio semantico. Il confine con SQL si traccia sulla natura della domanda: se è «trova i documenti che trattano lo stesso tema» serve un vettoriale; se è «trova tutti gli ordini sopra 100 euro» basta un relazionale.

Ottimizzazioni dei Database Vettoriali: Quantizzazione e Ricerca Ibrida

Oltre alle caratteristiche di base, tre proprietà distinguono un database vettoriale usabile in produzione da un prototipo: il controllo dell’occupazione di memoria, la combinazione dei segnali di ricerca e l’integrazione diretta con i modelli.

1. Quantizzazione e controllo dei costi: poiché la memoria è il vero collo di bottiglia, i motori moderni offrono quantizzazione scalare e binaria dei vettori, che comprime drasticamente l’occupazione di RAM a fronte di una perdita di accuratezza contenuta e recuperabile con una fase di re-scoring sui vettori originali. È la leva principale per rendere sostenibile un indice da decine di milioni di embeddings.
2. Ricerca ibrida: la pura similarità densa fallisce su codici prodotto, nomi propri e sigle. Per questo la combinazione tra vettori densi e segnali lessicali sparsi (BM25 e varianti), con successivo riordinamento tramite un reranker, è diventata la configurazione predefinita nei sistemi di produzione.
3. Integrazione con l’ecosistema AI: l’interfaccia di questi sistemi è pensata per stare dentro una pipeline di machine learning: SDK client per i linguaggi del data engineering, connettori pronti per i framework di orchestrazione degli LLM e, in alcuni motori, la generazione degli embeddings direttamente lato server, che evita di mantenere un servizio intermedio. Non eseguono i modelli predittivi: li servono.

Database Vettoriali vs Database Tradizionali: Confronto Diretto

Il confronto tra database vettoriali e database tradizionali si riduce a una distinzione chiave: struttura rigida con query esatte contro schema flessibile con ricerca per somiglianza. Le due tecnologie sono spesso complementari più che alternative. Ecco un riepilogo strutturato sulle dimensioni più rilevanti per un progetto AI o aziendale.

Tabella di Confronto tra Database Vettoriali e Database Tradizionali

Architetture Ibride: Database Vettoriale e Relazionale Insieme

La scelta non è necessariamente esclusiva: molte architetture moderne adottano un approccio ibrido, affiancando un database relazionale per i dati transazionali a un database vettoriale per le funzionalità di ricerca semantica e raccomandazione. PostgreSQL stesso offre l’estensione pgvector per supportare casi d’uso ibridi nativamente, ed è disponibile praticamente su tutti i Postgres gestiti in cloud.

Cosa è Cambiato nel 2026: la Convergenza tra SQL e Vettoriale

La novità più rilevante degli ultimi due anni non è un nuovo motore vettoriale, ma il fatto che la ricerca vettoriale sia diventata una feature dei database tradizionali. Oracle ha introdotto il tipo di dato VECTOR e la AI Vector Search, oggi documentata nella release Oracle AI Database 26ai che ha preso il posto della 23ai. Microsoft ha portato il tipo VECTOR e la funzione VECTOR_DISTANCE dentro SQL Server 2025, disponibile in versione generale da novembre 2025, con gli indici vettoriali DiskANN già GA su Azure SQL Database e ancora in preview nel prodotto on-premise. MySQL HeatWave ha aggiunto un vector store integrato, MongoDB Atlas ed Elasticsearch/OpenSearch offrono indici vettoriali gestiti, e pgvector ha continuato a maturare sul fronte dei filtri combinati e dell’efficienza degli indici. Sul fronte opposto, i motori vettoriali nativi hanno assorbito funzionalità “da database”: filtri strutturati sui payload, multi-tenancy, snapshot, controllo degli accessi.

Il punto tecnico su cui si è concentrata questa convergenza è il filtro combinato con la ricerca approssimata: cercare i vettori più simili e insieme imporre una condizione sui metadati (un tenant, una data, una categoria). L’approccio ingenuo, cioè prendere i primi k risultati e poi filtrarli, restituisce liste semivuote quando il filtro è selettivo. Le implementazioni recenti affrontano esattamente questo problema: pgvector con le scansioni iterative dell’indice introdotte nella versione 0.8.0 (ottobre 2024), SQL Server con il filtraggio iterativo applicato durante la ricerca, i motori nativi valutando il predicato durante l’attraversamento del grafo. Se il vostro caso d’uso prevede filtri stretti, è la prima cosa da verificare in un benchmark: è lì che le differenze tra sistemi si vedono davvero.

Come Scegliere tra Database Vettoriale e SQL nel 2026

La conseguenza pratica per chi deve decidere oggi è netta e va contro l’istinto del 2023:

• Sotto il milione di vettori, con dati già in Postgres e un team senza esperienza di infrastruttura AI, l’estensione vettoriale del database esistente è quasi sempre la scelta razionale: un sistema in meno da gestire, transazionalità e backup inclusi.
• Oltre le decine di milioni di vettori, o con requisiti stringenti di latenza, filtri complessi, quantizzazione e aggiornamento continuo dell’indice, un motore vettoriale dedicato mantiene un vantaggio strutturale.
• In ogni caso serve una fonte di verità: il database vettoriale è un indice derivato, ricostruibile. I documenti originali e i metadati vanno tenuti altrove, perché prima o poi cambierete modello di embedding e dovrete ricalcolare tutto.

Il Modello di Embedding Vincola più del Database Vettoriale

La scelta del modello di embedding vincola un progetto più della scelta del database vettoriale, ed è il punto più sottovalutato. Dimensione del vettore, lingua supportata e costo per milione di token determinano tanto la qualità del retrieval quanto la bolletta mensile, e cambiarli significa re-indicizzare l’intero corpus.

Qdrant: Memorizzazione Vettoriale per il RAG con LLM

Qdrant è un database vettoriale open-source scritto in Rust che si distingue per la capacità di integrarsi con i modelli di machine learning, in particolare nel contesto della Retrieval-Augmented Generation. La documentazione ufficiale di Qdrant evidenzia come il sistema sia ottimizzato per le prestazioni dei Large Language Models, offrendo accesso efficiente e scalabile a vasti set di dati vettoriali. La sua tecnologia permette memorizzazione efficiente ed elaborazione rapida delle query, essenziale per applicazioni di intelligenza artificiale di ultima generazione.

Rispetto alle prime versioni, l’evoluzione più utile in produzione riguarda tre aspetti: la quantizzazione scalare e binaria, che abbatte l’occupazione di memoria degli indici; il supporto ai vettori sparsi, che consente di implementare ricerca ibrida denso+lessicale in un unico sistema senza affiancare un motore full-text; e il filtraggio strutturato sui payload applicato durante la ricerca ANN, che evita il classico problema del recupero dei primi k risultati poi svuotato dai filtri applicati a posteriori.

Il Ruolo di Qdrant nel RAG

La Retrieval-Augmented Generation (RAG) è una metodologia, introdotta da Lewis et al. (2020) in un paper NeurIPS, che arricchisce i modelli di linguaggio combinando capacità generative con un meccanismo di recupero esterno. Qdrant si inserisce in questo processo memorizzando rappresentazioni vettoriali dei dati, che possono essere rapidamente interrogate dai LLM per recuperare informazioni pertinenti e aggiornate. Questo recupero di contesto arricchito prima della generazione della risposta migliora notevolmente l’accuratezza e la pertinenza degli output del modello, come avviene nel framework Cheshire Cat, che sfrutta proprio questa architettura.

Vale la pena ricordare che il RAG non è l’unica architettura possibile: con finestre di contesto molto ampie si può precaricare l’intera base di conoscenza nella cache del modello (CAG) o esporla come knowledge base strutturata, e in quegli scenari il database vettoriale pesa meno o sparisce del tutto. Abbiamo messo a confronto le tre impostazioni, con i rispettivi limiti di costo e freschezza, nella guida alle architetture RAG, CAG e LLM wiki.

Va detto che il database vettoriale è solo un pezzo della catena. Nelle implementazioni recenti la qualità delle risposte dipende almeno quanto dalla strategia di suddivisione dei documenti in chunk, dalla ricerca ibrida, dal reranking dei candidati e dalla valutazione sistematica del retrieval. Un motore veloce con un chunking sbagliato produce risposte sbagliate, solo più in fretta: su come mettere insieme queste scelte in un progetto concreto abbiamo raccolto i criteri nella guida al RAG aziendale su misura.

Applicazioni di Qdrant nell’IA e nell’Apprendimento Automatico

1. Miglioramento della Comprensione della Lingua Naturale: Utilizzando Qdrant in combinazione con la RAG, i LLM possono raggiungere una comprensione del contesto notevolmente migliorata, cruciale per applicazioni come assistenti virtuali e sistemi interattivi avanzati. È anche ciò che separa un chatbot a regole da un chatbot AI: il primo segue un albero di risposte predefinite, il secondo recupera il contesto pertinente prima di formulare la risposta.
2. Personalizzazione e Scalabilità: Con Qdrant è possibile integrare dinamicamente nuovi dati nei LLM senza la necessità di riaddestrare completamente i modelli. Questo aspetto è fondamentale per mantenere le applicazioni di intelligenza artificiale aggiornate con le ultime informazioni senza compromettere la scalabilità o le prestazioni.
3. Ricerca Semantica Aziendale: Le imprese possono utilizzare Qdrant per costruire motori di ricerca interni capaci di comprendere il significato delle query degli utenti, non solo le parole chiave, restituendo risultati contestualmente rilevanti da documenti, email e knowledge base aziendali.
4. Agenti che consultano più fonti: nei sistemi agentici il retrieval non è un’unica chiamata ma una sequenza di interrogazioni con riformulazione della query. Qui la latenza del singolo lookup si moltiplica, e la scelta del motore vettoriale torna a pesare sull’esperienza finale.

Qdrant vs Database SQL Tradizionali

Mentre i database SQL tradizionali sono ottimizzati per gestire transazioni e query su dati strutturati con rigidità schema-based, Qdrant eccelle nell’ambito dei dati ad alta dimensionalità, tipici delle applicazioni di AI. Questa capacità di gestire grandi volumi di dati vettoriali e di eseguire ricerche di somiglianza velocemente lo rende ideale per scenari in cui il tempo di risposta è critico e dove i dati evolvono continuamente. Il rovescio della medaglia resta l’assenza di garanzie transazionali complete: per questo, in architetture serie, il vettoriale affianca il relazionale e non lo sostituisce.

Database vettoriale vs database a grafo: differenze e quando usarli insieme

Un database a grafo (Neo4j, Amazon Neptune, ArangoDB) memorizza entità come nodi e relazioni esplicite come archi, ottimizzando le query che attraversano connessioni: «amici degli amici», «percorso più breve tra A e B», «chi ha acquistato dopo chi». Un database vettoriale cerca invece somiglianza semantica tra rappresentazioni numeriche: nessuna relazione deve essere dichiarata a priori, il sistema la scopre per vicinanza geometrica. La differenza pratica è questa: il grafo lavora su connessioni già codificate, il vettoriale scopre affinità latenti. I due sono complementari, non alternativi, e nessuno dei due sostituisce il relazionale per le operazioni transazionali.

Anche qui il confine si è assottigliato. Neo4j offre indici vettoriali nativi basati su HNSW, con similarità del coseno o euclidea, quindi un database a grafo può ospitare gli embeddings accanto ai nodi senza un secondo sistema. Resta vero che un indice vettoriale dentro un grafo è pensato per casi d’uso misti, non per competere con un motore dedicato su decine di milioni di vettori e filtri stretti.

Grafo della conoscenza vs database vettoriale: il pattern GraphRAG

Un grafo della conoscenza (knowledge graph) organizza le informazioni come nodi collegati da archi con relazioni esplicite e tipizzate: «Marte è un pianeta», «Einstein ha sviluppato la relatività». Un database vettoriale memorizza rappresentazioni numeriche e trova elementi simili per distanza geometrica, senza nominare le relazioni tra loro. Il grafo risponde bene a query di traversata («trova tutti gli autori che collaborano con X») e a ragionamenti su strutture note; il database vettoriale eccelle nella ricerca semantica su testo non strutturato. Nei sistemi RAG più avanzati i due si combinano nel pattern GraphRAG, formalizzato da Edge et al. di Microsoft Research (2024): un LLM estrae entità e relazioni dal corpus, il grafo fornisce contesto strutturato e riassunti per comunità di entità, il vettoriale recupera i chunk rilevanti. La scelta dipende dal dominio: se le relazioni esplicite tra entità sono il cuore del problema, vale la pena costruire il grafo; se il problema è ritrovare documenti pertinenti tra migliaia, il vettoriale è la scelta più diretta.

Quando Usare un Database Vettoriale e Quando un Database SQL

Scegli un database SQL quando i tuoi dati sono strutturati, transazionali e le query richiedono filtri esatti; scegli un database vettoriale quando devi gestire embeddings, ricerca semantica o alimentare un LLM con contesto. Ecco alcune linee guida pratiche.

Quando Conviene un Database SQL

• I tuoi dati hanno una struttura tabellare chiara e stabile (ordini, clienti, fatture).
• Hai bisogno di garanzie ACID complete per transazioni finanziarie o critiche.
• Le query riguardano filtri esatti, aggregazioni e join tra entità correlate.
• Il tuo team ha competenze consolidate su tecnologie relazionali.
• Il volume di embeddings è modesto: in quel caso un’estensione vettoriale sul database esistente evita di aggiungere un servizio da mantenere.

Quando Serve un Database Vettoriale

• Devi implementare una pipeline RAG per arricchire un LLM con conoscenza aziendale: una decisione che va valutata insieme all’alternativa dell’addestramento, come spieghiamo nel confronto RAG vs fine-tuning per casi d’uso enterprise.
• Vuoi costruire un motore di ricerca semantica su testi, immagini o audio.
• Stai sviluppando sistemi di raccomandazione basati sulla somiglianza di contenuto.
• Lavori con embeddings prodotti da modelli linguistici o multimodali e prevedi milioni di vettori con aggiornamenti frequenti.
• Ti servono filtri strutturati applicati durante la ricerca per somiglianza, multi-tenancy o quantizzazione per contenere i costi di memoria.

Resta valida la regola generale dei progetti AI: se il conto economico non torna, il problema quasi mai è la tecnologia, ma il caso d’uso che le è stato messo intorno.

Database Vettoriale in Produzione: Costi, Metrica e Migrazioni

Sono le questioni che arrivano quando il prototipo funziona e bisogna decidere se metterlo in produzione: quanto costa, quale metrica scegliere, cosa succede il giorno in cui si cambia modello.

Il Costo Reale di un Database Vettoriale in Produzione

Il costo dominante è la memoria, non lo storage. L’ordine di grandezza si calcola a mano: un vettore da 1.536 dimensioni in float32 occupa circa 6 KB, quindi un milione di vettori sono circa 6 GB di soli dati, a cui si aggiungono qualche centinaio di byte per vettore per i collegamenti del grafo HNSW. La quantizzazione scalare a 8 bit divide l’occupazione per quattro, quella binaria per trentadue, al prezzo di un re-scoring sui vettori originali per recuperare accuratezza. Il secondo costo è il calcolo degli embeddings: si paga una volta sull’intero corpus, ma si ripaga per intero a ogni cambio di modello. Chi fa il preventivo guardando solo il canone mensile del servizio vettoriale sbaglia la voce più grande.

La Metrica di Distanza si Eredita dal Modello

La metrica di distanza giusta è quella indicata dalla scheda del modello di embedding che state usando: si eredita, non si sceglie. Per i modelli di testo è quasi sempre il coseno; sui vettori normalizzati il prodotto scalare produce lo stesso ordinamento ed è più veloce; la distanza euclidea resta comune su immagini e feature non normalizzate. Usare la metrica sbagliata non genera errori: genera risultati peggiori in silenzio. E poiché la metrica si fissa alla creazione della collezione, correggerla dopo significa ricrearla.

Cambiare Modello di Embedding Impone la Re-indicizzazione

Cambiare modello di embedding obbliga a ricalcolare tutti i vettori del corpus. I vettori prodotti da due modelli diversi non sono confrontabili tra loro nemmeno quando hanno la stessa dimensione: vivono in spazi differenti, e mescolarli produce un indice che risponde senza avere senso. La migrazione corretta è costruire una seconda collezione in parallelo, valutarla su un set di query di riferimento e commutare solo dopo il confronto. È il motivo per cui i documenti originali vanno conservati in una fonte di verità separata: senza il corpus di partenza, il giorno del cambio modello non avete nulla da re-indicizzare.

pgvector o Motore Dedicato: Dove Sta la Soglia

La soglia non è solo il numero di vettori. Con i dati già in Postgres, un corpus sotto il milione di vettori e nessun requisito di latenza aggressivo, l’estensione è la scelta economica: un sistema in meno, backup e transazioni inclusi. Il passaggio a un motore dedicato si giustifica quando compaiono insieme almeno due tra questi fattori: decine di milioni di vettori, budget di RAM che impone la quantizzazione, filtri molto selettivi combinati con la ricerca ANN, aggiornamenti continui dell’indice, multi-tenancy. Il filtro selettivo è il discriminante che si sottovaluta di più: è lì che le architetture si comportano in modo diverso, e va misurato sul proprio carico prima di decidere.

Perché il Vettoriale Non Sostituisce il Relazionale

Un database vettoriale non sostituisce il relazionale, e trattarlo come sostituto è l’errore architetturale più costoso. Il database vettoriale è un indice derivato e ricostruibile: non offre le garanzie transazionali complete che servono a ordini, pagamenti e anagrafiche, e per progetto rinuncia alla ricerca esatta. Ordini e clienti restano sul relazionale, gli embeddings stanno nell’indice vettoriale, e se l’indice si perde lo si ricostruisce dalla fonte di verità.

Finestre di Contesto Lunghe e Ruolo del Database Vettoriale

Le finestre di contesto lunghe riducono il ruolo del database vettoriale solo quando il corpus è piccolo e stabile. In quel caso precaricarlo nel contesto del modello (CAG) evita del tutto l’infrastruttura di retrieval. Se cresce oltre la finestra, cambia spesso o va filtrato per utente e permessi, il recupero selettivo resta necessario, e con esso l’indice vettoriale. Il confronto per esteso, con i limiti di costo e freschezza di ciascuna impostazione, sta nella guida a RAG, CAG e LLM wiki.

Fonti:

• Qdrant Documentation, Vector Search Engine Overview. qdrant.tech/documentation
• Qdrant Documentation, Quantization Guide. qdrant.tech/documentation/guides/quantization
• Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arxiv.org/abs/2005.11401
• Edge, D. et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. Microsoft Research. arxiv.org/abs/2404.16130
• Wang, J. et al. (2021). Milvus: A Purpose-Built Vector Data Management System. ACM SIGMOD. dl.acm.org/doi/10.1145/3448016.3457550
• Malkov, Y. A., & Yashunin, D. A. (2018). Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs. IEEE TPAMI. arxiv.org/abs/1603.09320
• Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks. Communications of the ACM. dl.acm.org/doi/10.1145/362384.362685
• pgvector, Open-source vector similarity search for Postgres. github.com/pgvector/pgvector
• PostgreSQL News, pgvector 0.8.0 Released (iterative index scans). postgresql.org/about/news/pgvector-080-released-2952
• Oracle, AI Vector Search User’s Guide (Oracle AI Database 26ai). docs.oracle.com/en/database/oracle/oracle-database/26/vecse
• Microsoft Learn, CREATE VECTOR INDEX (Transact-SQL), SQL Server 2025 e Azure SQL. learn.microsoft.com/en-us/sql/t-sql/statements/create-vector-index-transact-sql
• Neo4j, Cypher Manual: Vector indexes. neo4j.com/docs/cypher-manual/current/indexes/semantic-indexes/vector-indexes