Executive summary
I sistemi di intelligenza artificiale moderni rappresentano testi, immagini e altri contenuti come sequenze di numeri in spazi matematici ad alta dimensionalità, e la capacità di cercare rapidamente i contenuti più simili tra loro in archivi di miliardi di elementi è diventata un requisito infrastrutturale critico. Sono nati sistemi di archiviazione specializzati che, grazie ad algoritmi di ricerca approssimata, riducono i tempi di interrogazione da ore a frazioni di secondo, accettando un margine di imprecisione controllato e generalmente trascurabile. L'analisi che segue esamina i principali algoritmi e le architetture disponibili, evidenziando che non esiste una soluzione universale: la scelta dipende dalla scala dei dati, dalla necessità di combinare la ricerca per similarità con filtri su attributi strutturati e dal livello di complessità operativa che l'organizzazione è disposta a gestire. Per archivi di dimensioni contenute, l'estensione di un sistema di gestione dati relazionale già in uso offre spesso il miglior equilibrio tra prestazioni e semplicità; per scale maggiori, i sistemi distribuiti nativi rappresentano l'unica opzione praticabile, al costo di una complessità architetturale significativa.
Background
La crescente adozione di modelli di rappresentazione distribuita, dai word embedding alle rappresentazioni multimodali prodotte da reti neurali profonde, ha generato un problema infrastrutturale concreto: come archiviare e interrogare in modo efficiente collezioni di vettori ad alta dimensionalità che possono raggiungere l'ordine dei miliardi di elementi. I sistemi di gestione dati tradizionali, progettati per operare su dati strutturati attraverso indici B-tree e query relazionali, risultano inadeguati quando la primitiva fondamentale diventa il calcolo della similarità tra vettori densi in spazi con centinaia o migliaia di dimensioni [1].
Il problema formale sottostante è la ricerca del nearest neighbor in spazi ad alta dimensionalità. Dato un insieme $S$ di $n$ punti in $\mathbb{R}^d$ e un vettore query $q$, si richiede di trovare il punto $p^ \in S$ che minimizza una funzione di distanza $d(q, p^)$, tipicamente la distanza euclidea $L_2$, il prodotto interno (inner product) o la similarità coseno. La ricerca esatta ha complessità computazionale che scala linearmente con $n$ e $d$, rendendo impraticabile l'interrogazione in tempo reale su collezioni di grandi dimensioni. Questo fenomeno, noto come curse of dimensionality, è stato formalizzato nel lavoro fondazionale di Indyk e Motwani, che nel 1998 hanno dimostrato che è possibile ottenere soluzioni approssimate con complessità sub-lineare accettando un fattore di approssimazione controllato [2].
L'approximate nearest neighbor search (ANN) costituisce il paradigma computazionale su cui si fondano tutti i vector database contemporanei. L'idea centrale consiste nel costruire strutture dati specializzate, indici, che consentano di restituire i $k$ vicini approssimativamente più simili alla query, con garanzie probabilistiche sulla qualità del risultato (recall) e tempi di risposta ordini di grandezza inferiori alla ricerca esauriente. Il trade-off fondamentale di ogni algoritmo ANN è la relazione tra recall (la proporzione di veri nearest neighbor restituiti), throughput (query al secondo), consumo di memoria e tempo di costruzione dell'indice [3].
Negli ultimi cinque anni, il panorama si è evoluto da librerie di indicizzazione standalone, come FAISS [4], sviluppata da Meta AI, e ScaNN [5], sviluppata da Google Research, verso sistemi di gestione dati completi che integrano storage persistente, replicazione, filtraggio su metadati e API distribuite. Pan et al. [1] identificano oltre venti sistemi commerciali apparsi dal 2020, suddivisibili in vector database nativi (Milvus, Qdrant, Weaviate, Pinecone, Chroma), estensioni di database relazionali (pgvector) e motori di ricerca vettoriale integrati in piattaforme esistenti. Questa analisi esamina le architetture di indicizzazione che ne costituiscono il nucleo algoritmico e i trade-off architetturali che emergono nella scelta tra le diverse soluzioni.
Architetture di indicizzazione
Gli algoritmi di approximate nearest neighbor search possono essere classificati in quattro famiglie principali: metodi basati su hashing, metodi basati su quantizzazione, metodi basati su partizionamento dello spazio e metodi basati su grafi. Ciascuna famiglia presenta caratteristiche distinte in termini di complessità computazionale, consumo di memoria e comportamento al variare della dimensionalità e della cardinalità del dataset [1, 3].
Locality-Sensitive Hashing (LSH)
Il Locality-Sensitive Hashing, introdotto da Indyk e Motwani [2], rappresenta il primo approccio teoricamente fondato alla ricerca approssimata. Una famiglia di funzioni hash $\mathcal{H}$ è detta $(r_1, r_2, p_1, p_2)$-sensitive se, per ogni coppia di punti $x, y$: se $d(x, y) \leq r_1$ allora $\Pr[h(x) = h(y)] \geq p_1$, e se $d(x, y) \geq r_2$ allora $\Pr[h(x) = h(y)] \leq p_2$, con $r_1 < r_2$ e $p_1 > p_2$. L'algoritmo proietta i vettori in spazi hash a bassa dimensionalità, dove punti vicini nello spazio originale hanno alta probabilità di collidere nello stesso bucket. La complessità di query è $O(n^\gamma)$ con $\gamma = \frac{\log(1/p_1)}{\log(1/p_2)}$, sub-lineare rispetto a $n$ ma con requisiti di memoria significativi dovuti alla necessità di mantenere multiple tabelle hash indipendenti [2].
Nonostante le solide garanzie teoriche, LSH è stato progressivamente superato in ambito pratico dai metodi basati su grafi, che offrono recall superiore a parità di throughput sulle dimensionalità tipiche degli embedding moderni (768-4096 dimensioni). LSH mantiene tuttavia vantaggi in scenari con requisiti di aggiornamento incrementale frequente e in contesti in cui le garanzie formali di approssimazione sono critiche.
Product Quantization (PQ)
La Product Quantization, proposta da Jégou, Douze e Schmid nel 2011 [6], affronta il problema della ricerca per similarità da una prospettiva complementare: la compressione dei vettori. L'idea consiste nel decomporre lo spazio $\mathbb{R}^d$ in un prodotto cartesiano di $m$ sottospazi a bassa dimensionalità $\mathbb{R}^{d/m}$ e nel quantizzare ciascun sottospazio indipendentemente attraverso un codebook appreso via $k$-means. Un vettore $x \in \mathbb{R}^d$ viene rappresentato da un codice compatto di $m$ indici, ciascuno di $\log_2 k$ bit, riducendo l'occupazione di memoria da $32d$ byte (float32) a $m \log_2 k$ bit. Con parametri tipici ($m = 8$, $k = 256$), un vettore a 768 dimensioni passa da 3072 byte a 8 byte, con un fattore di compressione di circa 384x.
La distanza tra un vettore query e un vettore quantizzato viene calcolata mediante lookup table pre-computate, evitando il calcolo esplicito nello spazio originale. Jégou et al. hanno validato l'approccio su un dataset di due miliardi di vettori, dimostrando che la combinazione di un Inverted File Index (IVF) con Product Quantization, nota come IVFPQ, consente di gestire collezioni di scala miliardaria con requisiti di memoria nell'ordine dei gigabyte anziché dei terabyte [6]. IVFPQ opera in due fasi: una quantizzazione grossolana (coarse quantizer) partiziona lo spazio in $K$ celle Voronoi tramite $k$-means, e all'interno di ciascuna cella i residui vengono compressi via PQ. La ricerca si limita alle $w$ celle più vicine alla query (con $w \ll K$), riducendo drasticamente il numero di confronti.
Hierarchical Navigable Small World (HNSW)
L'algoritmo HNSW, proposto da Malkov e Yashunin [7], rappresenta il metodo dominante nei vector database contemporanei. L'architettura si fonda sulla costruzione incrementale di un grafo di prossimità multi-livello, ispirato alla struttura delle skip list. Gli elementi vengono inseriti in livelli successivi con probabilità esponenzialmente decrescente: il livello 0 contiene tutti gli elementi, il livello 1 un sottoinsieme, e così via. Ogni livello costituisce un navigable small world graph in cui i nodi sono connessi ai propri vicini approssimati.
La ricerca procede top-down: partendo dal livello più alto (più sparso), l'algoritmo esegue una greedy search verso il nodo più vicino alla query, poi scende al livello successivo utilizzando il risultato come punto di ingresso, fino a raggiungere il livello 0 dove esegue la ricerca finale ad alta risoluzione. Questa struttura gerarchica consente una complessità di ricerca $O(\log n)$ con elevato recall, un risultato significativamente superiore rispetto ai grafi di prossimità piatti [7].
I parametri chiave che controllano il trade-off accuratezza-prestazioni sono: $M$ (numero massimo di connessioni per nodo), $ef_{construction}$ (dimensione della lista dei candidati durante la costruzione) e $ef_{search}$ (dimensione della lista dei candidati durante la ricerca). Valori più elevati di $M$ e $ef$ producono recall superiore a costo di maggiore consumo di memoria e latenza. Secondo i benchmark ANN-Benchmarks [3], le implementazioni HNSW (hnswlib, FAISS-HNSW) raggiungono consistentemente i migliori compromessi recall-throughput sulla maggior parte dei dataset di riferimento, con recall superiore al 99% a throughput dell'ordine delle migliaia di query al secondo per dataset nell'ordine dei milioni di vettori.
Il principale svantaggio di HNSW è il consumo di memoria: l'intero grafo deve risiedere in RAM per garantire le prestazioni attese. Per un dataset di un miliardo di vettori a 768 dimensioni in float32, il solo storage dei vettori richiede circa 3 TB, a cui si aggiunge l'overhead del grafo. Questa limitazione ha motivato lo sviluppo di approcci ibridi che combinano HNSW con tecniche di quantizzazione.
DiskANN e l'indicizzazione su storage persistente
DiskANN, proposto da Subramanya et al. nel 2019 [8], affronta direttamente il collo di bottiglia della memoria di HNSW introducendo un'architettura che sfrutta SSD per lo storage dell'indice. Il sistema si basa su Vamana, un nuovo algoritmo di costruzione di grafi di prossimità progettato per minimizzare il numero di accessi a disco durante la ricerca. A differenza di HNSW, Vamana produce un grafo piatto (single-layer) con un raggio di ricerca ridotto, ottimizzato per il pattern di accesso sequenziale degli SSD.
L'architettura DiskANN mantiene in memoria solo i vettori compressi via PQ (per un calcolo approssimato delle distanze durante la navigazione del grafo) e memorizza su disco il grafo completo con i vettori a precisione piena. Quando un nodo viene visitato durante la ricerca, i suoi vicini vengono caricati da disco in un singolo accesso sequenziale. Sul dataset SIFT1B (un miliardo di vettori a 128 dimensioni), DiskANN ha dimostrato di servire oltre 5000 query al secondo con latenza media inferiore a 3 ms e recall (1-recall@1) superiore al 95%, su una singola workstation con 64 GB di RAM e un SSD, un risultato che le soluzioni precedenti (FAISS, IVFOADC+G+P) a parità di footprint di memoria non superavano il 50% di recall [8].
L'approccio DiskANN è stato successivamente integrato in diversi sistemi: Microsoft lo ha adottato nel proprio servizio Azure AI Search, e il progetto open-source pgvectorscale ha implementato una variante denominata StreamingDiskANN per estendere le capacità di pgvector su dataset di larga scala.
Anisotropic Vector Quantization (ScaNN)
Google Research ha proposto nel 2020 un approccio complementare con ScaNN (Scalable Nearest Neighbors), basato su una tecnica di quantizzazione anisotropa [5]. L'osservazione chiave è che nella ricerca per Maximum Inner Product Search (MIPS), l'errore di quantizzazione non ha impatto uniforme: l'errore sulla componente parallela al vettore originale è più dannoso dell'errore sulla componente ortogonale, poiché influenza direttamente lo score di similarità. La funzione di loss anisotropa penalizza quindi in modo asimmetrico le due componenti dell'errore di quantizzazione.
Sui benchmark ANN-Benchmarks, ScaNN ha dimostrato di raggiungere un throughput circa doppio rispetto alla libreria più veloce successiva a parità di recall, un risultato ottenuto sul dataset glove-100-angular [5]. L'approccio è particolarmente efficace per la ricerca MIPS, che corrisponde alla primitiva utilizzata nella maggior parte dei sistemi di retrieval basati su embedding di modelli di linguaggio.
Analisi delle soluzioni disponibili
Il panorama dei vector database può essere organizzato in tre categorie architetturali: sistemi nativi distribuiti, sistemi nativi single-node e estensioni di database esistenti. Ciascuna categoria riflette scelte architetturali fondamentali che determinano i limiti operativi del sistema [1].
Sistemi nativi distribuiti
Milvus rappresenta, per numero di deployment documentati e maturità delle pubblicazioni accademiche [9, 10], il sistema open-source con l'architettura distribuita più consolidata. Sviluppato sotto la governance della LF AI & Data Foundation, Milvus adotta un design cloud-native con separazione completa tra storage (object storage come S3 o MinIO), compute (query node stateless), coordinamento (etcd) e message queue (Kafka o Pulsar) [9, 10]. L'architettura a microservizi consente scaling orizzontale indipendente di ciascun componente. Wang et al. [9] descrivono il design iniziale, mentre Guo et al. [10] documentano l'evoluzione verso l'architettura completamente disaggregata di Milvus 2.0. Il sistema supporta molteplici algoritmi di indicizzazione (HNSW, IVF_FLAT, IVF_PQ, DiskANN) ed è progettato per gestire collezioni nell'ordine dei miliardi di vettori con aggiornamenti in tempo reale tramite streaming.
Il costo di questa flessibilità è una complessità operativa significativa: un deployment produttivo richiede la gestione di etcd, un message broker, object storage e multipli nodi compute. Per dataset inferiori ai cento milioni di vettori, l'overhead architetturale può risultare sproporzionato rispetto ai requisiti.
Pinecone adotta un approccio diametralmente opposto: un servizio completamente gestito con architettura proprietaria e serverless. L'utente interagisce esclusivamente tramite API, senza visibilità né controllo sugli algoritmi di indicizzazione o sulla configurazione dello storage sottostante. Questa opacità semplifica l'adozione ma limita l'ottimizzazione fine e introduce una dipendenza totale dal fornitore. Pinecone risulta competitivo per team con risorse operative limitate che necessitano di avvio rapido, ma la mancanza di trasparenza architetturale rappresenta un vincolo significativo per applicazioni che richiedono garanzie di performance prevedibili o conformità a requisiti di data residency.
Sistemi nativi single-node
Qdrant, sviluppato in Rust, si distingue per un'architettura progettata attorno alla ricerca filtrata. L'implementazione utilizza una variante modificata di HNSW con un motore di storage proprietario (Gridstore) e sfrutta istruzioni SIMD per il calcolo delle distanze. L'elemento architetturale più rilevante è l'integrazione dei filtri direttamente nella traversata del grafo HNSW: anziché applicare filtri in pre- o post-processing (strategie che degradano rispettivamente il recall o il throughput), Qdrant valuta le condizioni di filtraggio durante la navigazione del grafo, selezionando la strategia ottimale in base alla cardinalità stimata del risultato filtrato [11]. Questa scelta architetturale rende Qdrant particolarmente efficace in scenari dove le query combinano similarità vettoriale con vincoli su metadati strutturati, un pattern dominante nelle applicazioni RAG (Retrieval-Augmented Generation) in produzione.
Weaviate, scritto in Go, integra nativamente la ricerca ibrida combinando un indice HNSW per la ricerca vettoriale con un indice invertito BM25F per la ricerca lessicale. I risultati delle due modalità vengono fusi tramite Reciprocal Rank Fusion (RRF), con un parametro $\alpha \in [0, 1]$ che controlla il bilanciamento tra componente semantica e lessicale [12]. L'architettura modulare consente di integrare servizi di vettorizzazione (OpenAI, Cohere, modelli locali) direttamente nel pipeline di ingestione, eliminando la necessità di un servizio esterno di generazione embedding. Weaviate 1.31 ha introdotto lo snapshotting degli indici HNSW, riducendo i tempi di avvio di 10-15x rispetto alla ricostruzione da write-ahead log, un miglioramento operativo significativo per deployment con indici di decine di milioni di oggetti [12].
Chroma occupa una nicchia distinta: un database vettoriale progettato per la semplicità e la prototipazione rapida. L'architettura utilizza un sistema di storage a tre livelli (buffer brute-force, cache HNSW in memoria, persistenza su disco in formato Apache Arrow) con SQLite per i metadati. Nel 2025, la riscrittura del core in Rust ha eliminato i colli di bottiglia legati al Global Interpreter Lock di Python, ottenendo miglioramenti di performance fino a 4x [13]. Chroma è efficace per workflow di sviluppo e proof-of-concept, ma la sua architettura single-process lo rende inadatto a deployment produttivi su dataset superiori ai pochi milioni di vettori.
Estensioni di database relazionali
pgvector estende PostgreSQL con tipi di dato vettoriali, operatori di similarità (distanza euclidea, prodotto interno, coseno) e indici ANN basati su HNSW e IVF_FLAT [14]. Il vantaggio principale è l'integrazione con l'ecosistema PostgreSQL: transazioni ACID, join con tabelle relazionali, backup e replicazione tramite strumenti consolidati. La versione 0.8.0 (ottobre 2024) ha introdotto miglioramenti significativi nelle performance delle query filtrate e nella costruzione degli indici HNSW [14].
Il progetto pgvectorscale, sviluppato da Timescale, estende ulteriormente pgvector con StreamingDiskANN, un'implementazione dell'algoritmo DiskANN ottimizzata per PostgreSQL. Secondo i benchmark pubblicati da Timescale su 50 milioni di embedding Cohere a 768 dimensioni, pgvectorscale ha raggiunto 471 QPS al 99% di recall, un risultato che gli autori riportano come 11.4x superiore rispetto a Qdrant (41 QPS) sullo stesso dataset e configurazione hardware [15]. I medesimi benchmark indicano latenza p95 inferiore di 28x e throughput superiore di 16x rispetto all'indice storage-optimized (s1) di Pinecone, a un costo inferiore del 75% su AWS EC2 auto-ospitato. È opportuno considerare che questi dati provengono dal team di sviluppo di pgvectorscale e che benchmark indipendenti su configurazioni equivalenti sono necessari per una validazione completa [15]. Questi risultati suggeriscono che, per organizzazioni con competenze PostgreSQL consolidate, l'approccio estensivo può offrire un rapporto costo-efficacia superiore rispetto ai vector database nativi, con il vantaggio di mantenere un unico stack tecnologico per dati relazionali e vettoriali.
La limitazione principale di pgvector rimane la scalabilità orizzontale: PostgreSQL è un sistema single-node per design, e le soluzioni di sharding (Citus, partizionamento nativo) aggiungono complessità senza raggiungere l'elasticità dei sistemi cloud-native distribuiti.
Librerie di indicizzazione
È importante distinguere i vector database dalle librerie di indicizzazione come FAISS [4]. FAISS, sviluppata da Meta AI, è una libreria C++ con binding Python che implementa i principali algoritmi ANN (IVF, PQ, HNSW e relative combinazioni), con supporto per esecuzione su GPU che consente di costruire grafi k-NN su 95 milioni di immagini in 35 minuti e di connettere un miliardo di vettori in meno di 12 ore utilizzando 4 GPU [4]. FAISS non è un database: non offre persistenza, replicazione, API di servizio o gestione di metadati. Rappresenta tuttavia il componente di indicizzazione su cui diversi vector database (incluso Milvus) costruiscono i propri servizi.
Limiti e problemi aperti
Il problema della ricerca filtrata
La maggioranza delle applicazioni reali richiede query che combinano similarità vettoriale con filtri su attributi strutturati, ad esempio, "trova i documenti semanticamente più simili alla query $q$, pubblicati dopo il 2023, nel dominio finanziario". Pan et al. [1] identificano il Filtering Approximate Nearest Neighbor search come uno dei cinque ostacoli principali alla gestione efficiente di dati vettoriali. Le strategie di pre-filtering (applicare i filtri prima della ricerca vettoriale) riducono il recall quando il filtro è molto selettivo, poiché l'indice ANN non è stato costruito sul sottoinsieme filtrato. Le strategie di post-filtering (applicare i filtri dopo la ricerca vettoriale) possono restituire un numero insufficiente di risultati se la maggioranza dei candidati viene eliminata. L'integrazione dei filtri direttamente nella traversata dell'indice, come implementato da Qdrant [11], rappresenta una soluzione promettente ma introduce complessità algoritmiche nella stima della cardinalità e nella pianificazione dell'esecuzione.
Costo degli aggiornamenti incrementali
Gli indici basati su grafi (HNSW, Vamana) sono progettati per l'inserimento incrementale, ma la cancellazione e la modifica di vettori esistenti rimangono operazioni costose. La rimozione di un nodo da un grafo HNSW richiede la riconnessione dei vicini per mantenere la navigabilità, un'operazione che può degradare la qualità dell'indice nel tempo. In scenari con elevato tasso di aggiornamento (churn), la ricostruzione periodica dell'indice può risultare necessaria, introducendo finestre di degradazione delle prestazioni [7].
Scalabilità oltre il singolo nodo
La distribuzione di un indice ANN su un cluster presenta sfide specifiche. Il partizionamento dei vettori tra nodi (sharding) richiede strategie che bilancino il carico mantenendo la qualità della ricerca: uno sharding random distribuisce uniformemente il carico ma richiede di interrogare tutti i nodi per ogni query, mentre uno sharding basato su clustering (partitioning by proximity) può introdurre sbilanciamenti e perdita di recall per query vicine ai confini delle partizioni. Milvus affronta questo problema con un'architettura a segmenti sealed e growing, dove i nuovi dati vengono accumulati in segmenti growing in memoria e periodicamente consolidati in segmenti sealed ottimizzati per la ricerca [10].
Curse of dimensionality e embedding ad altissima dimensionalità
L'efficacia degli algoritmi ANN degrada al crescere della dimensionalità: in spazi con $d > 1000$, le distanze tra punti tendono a concentrarsi, riducendo la discriminatività della metrica di similarità e la capacità degli indici di potare lo spazio di ricerca [1, 2]. I modelli di embedding recenti tendono a produrre rappresentazioni con dimensionalità crescente (1536 per text-embedding-3-large di OpenAI, 4096 per alcuni modelli open-source), accentuando questa pressione. Le tecniche di riduzione dimensionale (PCA, random projection, Matryoshka embedding) offrono mitigazioni parziali ma introducono perdita di informazione che si traduce in riduzione del recall.
Assenza di un benchmark standardizzato end-to-end
ANN-Benchmarks [3] costituisce il riferimento de facto per la valutazione degli algoritmi di indicizzazione, ma opera su dataset statici di dimensioni moderate (decine di milioni di vettori) e non cattura aspetti critici per i deployment produttivi: prestazioni sotto carico concorrente, impatto degli aggiornamenti incrementali, efficacia della ricerca filtrata, costi di storage e latenze di coda (p99, p999). L'assenza di un framework di benchmarking che integri questi aspetti rende difficile il confronto oggettivo tra sistemi in condizioni operative realistiche.
Implicazioni pratiche
La scelta di un vector database per un deployment produttivo dipende da un insieme di variabili interdipendenti che vanno oltre le pure prestazioni algoritmiche. L'analisi che precede consente di delineare alcune raccomandazioni basate sui trade-off emersi.
Per organizzazioni che operano su dataset inferiori ai dieci milioni di vettori e dispongono già di un'infrastruttura PostgreSQL, pgvector con estensione pgvectorscale rappresenta la soluzione con il miglior rapporto costo-complessità: le prestazioni sono competitive con i vector database nativi, l'integrazione con dati relazionali è nativa, e lo stack operativo rimane unificato [14, 15]. Questa configurazione è particolarmente indicata per applicazioni RAG enterprise dove i vettori coesistono con metadati strutturati complessi.
Per dataset nell'ordine delle decine di milioni di vettori con requisiti stringenti di ricerca filtrata, Qdrant e Weaviate offrono architetture ottimizzate per questo pattern d'uso. Qdrant è preferibile quando il filtraggio su metadati è il requisito dominante; Weaviate è indicato quando la ricerca ibrida (semantica + lessicale) è un requisito primario [11, 12].
Per dataset nell'ordine delle centinaia di milioni o miliardi di vettori, Milvus rimane la soluzione open-source con l'architettura distribuita più matura, al costo di una complessità operativa significativa [9, 10]. Pinecone rappresenta un'alternativa per team che accettano il vendor lock-in in cambio dell'eliminazione della complessità operativa.
Un aspetto spesso sottovalutato nella fase di valutazione è il costo totale di ownership a regime: il consumo di memoria degli indici HNSW in-memory può rendere proibitivi i costi infrastrutturali su cloud provider per dataset di larga scala. L'adozione di indici disk-based (DiskANN, StreamingDiskANN) o la combinazione di indici HNSW con quantizzazione aggressiva può ridurre i costi di un ordine di grandezza, come dimostrato dai benchmark pgvectorscale [8, 15]. La valutazione deve inoltre considerare l'evoluzione del dataset nel tempo: un sistema che risulta ottimale a un milione di vettori potrebbe richiedere una migrazione architetturale completa a cento milioni.
Riferimenti
[1] J. J. Pan, J. Wang, G. Li, "Survey of Vector Database Management Systems," The VLDB Journal, 2024. https://arxiv.org/abs/2310.14021
[2] P. Indyk, R. Motwani, "Approximate Nearest Neighbors: Towards Removing the Curse of Dimensionality," in Proc. 30th Annual ACM Symposium on the Theory of Computing (STOC), 1998.
[3] M. Aumüller, E. Bernhardsson, A. Faithfull, "ANN-Benchmarks: A Benchmarking Tool for Approximate Nearest Neighbor Algorithms," Information Systems, vol. 87, 2020. https://ann-benchmarks.com/
[4] J. Johnson, M. Douze, H. Jégou, "Billion-Scale Similarity Search with GPUs," IEEE Transactions on Big Data, vol. 7, no. 3, 2021. https://arxiv.org/abs/1702.08734
[5] R. Guo et al., "Accelerating Large-Scale Inference with Anisotropic Vector Quantization," in Proc. ICML, 2020. https://arxiv.org/abs/1908.10396
[6] H. Jégou, M. Douze, C. Schmid, "Product Quantization for Nearest Neighbor Search," IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 33, no. 1, pp. 117-128, 2011. https://ieeexplore.ieee.org/document/5432202
[7] Y. A. Malkov, D. A. Yashunin, "Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs," IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 42, no. 4, 2020. https://arxiv.org/abs/1603.09320
[8] S. J. Subramanya et al., "DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node," in Proc. NeurIPS, 2019. https://proceedings.neurips.cc/paper/2019/hash/09853c7fb1d3f8ee67a61b6bf4a7f8e6-Abstract.html
[9] J. Wang et al., "Milvus: A Purpose-Built Vector Data Management System," in Proc. ACM SIGMOD, 2021. https://dl.acm.org/doi/10.1145/3448016.3457550
[10] R. Guo et al., "Manu: A Cloud Native Vector Database Management System," Proc. VLDB Endow., vol. 15, no. 12, 2022. https://www.vldb.org/pvldb/vol15/p3548-yan.pdf
[11] Qdrant, "Qdrant — High-Performance Vector Search Engine," documentazione ufficiale, 2025. https://qdrant.tech/documentation/overview/
[12] Weaviate, "Weaviate Documentation," documentazione ufficiale, 2025. https://docs.weaviate.io/
[13] Chroma, "Chroma — Open-Source Embedding Database," GitHub repository, 2025. https://github.com/chroma-core/chroma
[14] pgvector, "Open-Source Vector Similarity Search for Postgres," GitHub repository, 2025. https://github.com/pgvector/pgvector
[15] Timescale, "pgvectorscale: DiskANN-based Vector Search for PostgreSQL," GitHub repository, 2025. https://github.com/timescale/pgvectorscale