Torna al blog
Vector Database a Confronto: Qdrant, pgvector e Quando Serve Davvero un Database Dedicato

Vector Database a Confronto: Qdrant, pgvector e Quando Serve Davvero un Database Dedicato

10 min di lettura1 visualizzazioni
di Marco Salmaso
Ogni sistema RAG ha bisogno di un posto dove salvare e cercare gli embedding. Meglio un database vettoriale dedicato come Qdrant o un'estensione come pgvector sul PostgreSQL che già usi? Come funzionano gli indici, quali sono i punti di forza di ciascuno e un criterio pratico per scegliere.

Perché Servono i Vector Database

Quando si costruisce un sistema RAG, un motore di ricerca semantica o un sistema di raccomandazione, i testi (o le immagini) vengono trasformati in embedding: vettori di centinaia o migliaia di numeri che rappresentano il significato del contenuto. Due frasi con significato simile producono vettori vicini nello spazio, anche se usano parole diverse.

Il problema diventa allora: dato un vettore di domanda, trova i vettori più vicini tra milioni di vettori salvati. Farlo confrontando la domanda con ogni singolo vettore (ricerca esatta, o brute force) funziona per poche migliaia di elementi, ma diventa lento al crescere dei dati. I vector database risolvono questo problema con indici specializzati per la ricerca approssimata dei vicini più prossimi (ANN, Approximate Nearest Neighbor).

Come Funzionano gli Indici

HNSW

L'indice più diffuso oggi è HNSW (Hierarchical Navigable Small World). Costruisce un grafo a più livelli in cui ogni vettore è collegato ai suoi vicini. La ricerca parte dal livello più alto, dove ci sono pochi nodi e collegamenti lunghi, e scende progressivamente verso livelli più densi, avvicinandosi al risultato. È un po' come cercare un indirizzo partendo dalle autostrade, poi le strade statali, poi le vie del quartiere.

HNSW offre ottimi tempi di ricerca e alta qualità dei risultati, al prezzo di un uso di memoria significativo e di tempi di costruzione dell'indice non trascurabili.

IVF

Gli indici IVF (Inverted File) dividono lo spazio in gruppi tramite clustering. Durante la ricerca si esplorano solo i gruppi più vicini alla domanda. Sono più leggeri da costruire, ma la qualità dipende dal numero di gruppi esplorati e richiedono di essere ricostruiti quando i dati cambiano molto.

Le metriche di distanza

Ogni indice lavora con una misura di distanza: coseno (la più comune per gli embedding testuali), prodotto scalare o distanza euclidea. La scelta deve essere coerente con il modello di embedding: la maggior parte dei modelli testuali moderni è pensata per la similarità coseno.

pgvector: i Vettori Dentro PostgreSQL

pgvector è un'estensione di PostgreSQL che aggiunge un tipo di dato vector e gli operatori per la ricerca di similarità. Supporta sia indici HNSW sia IVFFlat.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documenti (
  id bigserial PRIMARY KEY,
  contenuto text,
  categoria text,
  embedding vector(768)
);

CREATE INDEX ON documenti
  USING hnsw (embedding vector_cosine_ops);

-- i 5 documenti più simili alla domanda, filtrati per categoria
SELECT id, contenuto
FROM documenti
WHERE categoria = 'procedure'
ORDER BY embedding <=> $1
LIMIT 5;

Punti di forza

  • Un solo database: dati relazionali e vettori stanno nello stesso posto, con transazioni, backup e permessi già noti.
  • SQL completo: si possono combinare ricerca vettoriale, join, filtri e aggregazioni in un'unica query.
  • Ecosistema: è disponibile su quasi tutti i servizi PostgreSQL gestiti, Supabase incluso, spesso con un clic.
  • Sicurezza integrata: su Supabase, ad esempio, le policy di Row Level Security si applicano anche alle tabelle con embedding.

Limiti

  • Con molti milioni di vettori e carichi elevati, le prestazioni richiedono tuning attento (memoria, parametri dell'indice).
  • La combinazione di filtri molto selettivi e ricerca approssimata può dare risultati incompleti se non configurata con cura.
  • Funzionalità avanzate (quantizzazione spinta, ricerca ibrida nativa, multi-vettore) sono meno mature rispetto ai database dedicati.

Qdrant: un Database Nato per i Vettori

Qdrant è un vector database open source scritto in Rust, progettato fin dall'inizio per la ricerca vettoriale. Si può usare in locale con Docker, su server propri o come servizio cloud gestito.

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, Filter, FieldCondition, MatchValue

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="documenti",
    vectors_config=VectorParams(size=768, distance=Distance.COSINE),
)

risultati = client.query_points(
    collection_name="documenti",
    query=vettore_domanda,
    query_filter=Filter(
        must=[FieldCondition(key="categoria", match=MatchValue(value="procedure"))]
    ),
    limit=5,
).points

Punti di forza

  • Filtri sul payload efficienti: ogni vettore porta con sé un payload JSON, e Qdrant integra i filtri direttamente nella navigazione dell'indice, mantenendo buoni risultati anche con filtri selettivi.
  • Quantizzazione: riduce drasticamente la memoria occupata dai vettori (scalare, binaria, prodotto) con una perdita di qualità controllabile.
  • Vettori multipli e sparsi: supporta più vettori per punto e vettori sparsi, utili per la ricerca ibrida che combina significato e parole chiave.
  • Prestazioni e scalabilità: pensato per collezioni grandi, con sharding e repliche.

Limiti

  • È un sistema in più da gestire, monitorare e salvare.
  • I dati relazionali restano altrove: servono sincronizzazione e attenzione alla coerenza tra database principale e collezione vettoriale.
  • Permessi e sicurezza vanno configurati a parte rispetto al database applicativo.

Le Altre Alternative

Il panorama è ampio. Chroma è molto popolare per prototipi e progetti locali grazie alla sua semplicità. Weaviate e Milvus sono alternative open source mature e orientate alla scala. Pinecone è un servizio completamente gestito che elimina l'infrastruttura in cambio di dipendenza dal fornitore. Molti database tradizionali, da Elasticsearch a MongoDB, hanno aggiunto la ricerca vettoriale.

Come Scegliere

Dopo aver lavorato con entrambi, il mio criterio pratico è questo.

Scegli pgvector se:

  • usi già PostgreSQL (o Supabase) per la tua applicazione;
  • hai fino a qualche milione di vettori;
  • ti servono join e filtri complessi tra vettori e dati relazionali;
  • vuoi ridurre al minimo i sistemi da mantenere.

Scegli Qdrant (o un database dedicato) se:

  • la ricerca vettoriale è il cuore del sistema e non un'aggiunta;
  • hai molti milioni di vettori o requisiti di latenza stringenti;
  • ti servono ricerca ibrida, quantizzazione o vettori multipli;
  • vuoi un componente indipendente da riutilizzare in più progetti, ad esempio esposto tramite un server MCP che offre strumenti di salvataggio e ricerca a qualsiasi assistente AI.

Per la maggior parte dei progetti che partono oggi, il consiglio è iniziare con pgvector se c'è già un PostgreSQL, e passare a un database dedicato solo quando emergono limiti concreti e misurati. Migrare gli embedding da un sistema all'altro non è complicato: il vero lavoro, la preparazione e la suddivisione dei documenti, resta valido.

Un Dettaglio che Conta più del Database

Una nota finale: la qualità di un sistema di ricerca semantica dipende molto più da come si dividono i documenti (chunking), da quale modello di embedding si usa e da come si filtrano i risultati che dalla scelta del database. Un pgvector ben alimentato batte un Qdrant riempito di chunk mal tagliati. Prima di ottimizzare l'indice, conviene sempre ottimizzare i dati.

Conclusioni

pgvector e Qdrant non sono concorrenti diretti: rispondono a esigenze diverse. Il primo porta i vettori dove i dati già vivono, con la semplicità di un unico sistema; il secondo offre funzionalità e prestazioni pensate specificamente per la ricerca vettoriale. Capire come funzionano gli indici e quali sono i propri requisiti reali è il modo migliore per evitare sia l'infrastruttura superflua sia i limiti scoperti troppo tardi.