Qdrant vs Chroma vs pgvector: Scegliere il database vettoriale giusto per RAG self-hosted

Qdrant vs Chroma vs pgvector: Scegliere il database vettoriale giusto per RAG self-hosted

La decisione Qdrant vs Chroma vs pgvector si riduce a un compromesso a tre vie: velocità specializzata, semplicità per i prototipi, o restare nell'ecosistema Postgres. Ogni approccio funziona, la domanda è quale compromesso si adatta alla tua pipeline RAG.

Riepilogo rapido: Quale database vettoriale dovresti scegliere?

Scegli Qdrant se hai bisogno di ricerca vettoriale di livello produzione con filtri avanzati, multi-tenancy, e non ti dispiace gestire un servizio separato.

Scegli Chroma se stai prototipando, vuoi sviluppo locale senza configurazione, o hai bisogno di passare da un'idea a un RAG funzionante in meno di un'ora.

Scegli pgvector (+ pgvectorscale) se esegui già PostgreSQL e vuoi la ricerca vettoriale senza aggiungere infrastruttura, specialmente ora che l'indice StreamingDiskANN di pgvectorscale ha colmato il divario di prestazioni.

Se stai costruendo un'applicazione RAG da zero, il resto di questo articolo ti aiuterà a scegliere le giuste fondamenta.

Prestazioni: Quanto è veloce ogni database?

Le prestazioni contano una volta superati pochi migliaia di documenti. Ecco dove questi tre divergono significativamente.

Qdrant

Qdrant è costruito da zero per la ricerca vettoriale. La sua implementazione in Rust e l'indice HNSW personalizzato forniscono latenza costantemente bassa, i benchmark mostrano una latenza di query di circa 94 ms anche sotto carico concorrente. Supporta quantizzazione scalare, binaria e di prodotto per comprimere i vettori e velocizzare la ricerca mantenendo il recall sopra il 95%.

Dove Qdrant eccelle davvero è la ricerca filtrata. A differenza dei database che trovano prima i vicini più prossimi e poi filtrano, l'HNSW filtrabile di Qdrant rispetta i vincoli dei metadati durante l'attraversamento del grafo. Ciò significa che non perdi recall combinando la ricerca vettoriale con filtri come category = "technical" o date > 2025-01-01.

Chroma

La versione 1.0 di Chroma ha riscritto il nucleo in Rust, offrendo scritture e query da 3 a 5 volte più veloci rispetto all'implementazione Python originale. Un aggiornamento successivo nell'agosto 2025 ha aggiunto la codifica vettoriale base64 per un ulteriore aumento del 70% del throughput.

Per dataset sotto un milione di vettori, Chroma è genuinamente veloce. Funziona integrato nel tuo processo Python senza overhead di rete, il che rende l'iterazione locale reattiva. Ma è un database a nodo singolo, nessuno sharding o replica incorporati.

pgvector + pgvectorscale

Questo è il cavallo oscuro. Il pgvector standard con HNSW è 5.250 volte più veloce di una scansione sequenziale, e pgvector 0.8.0 ha aggiunto la scansione iterativa dell'indice per risolvere il problema di over-filtering che affliggeva le versioni precedenti.

Ma la storia vera è pgvectorscale. L'estensione di Timescale aggiunge l'indice StreamingDiskANN, ispirato dalla ricerca DiskANN di Microsoft, che memorizza l'indice su disco invece che in RAM. Su un benchmark di 50 milioni di embedding Cohere (768 dimensioni), pgvectorscale ha raggiunto 471 QPS con il 99% di recall. Questo è un throughput 11,4 volte superiore ai 41 QPS di Qdrant allo stesso livello di recall, e una latenza p95 28 volte inferiore all'indice ottimizzato per lo storage di Pinecone.

Il problema? Questi benchmark hanno utilizzato una potente istanza EC2. I tuoi risultati dipendono dall'hardware. Ma la traiettoria è chiara: PostgreSQL non è più l'opzione "abbastanza buona" per la ricerca vettoriale, è genuinamente competitivo.

Verdetto: pgvector + pgvectorscale vince sui numeri grezzi dei benchmark. Qdrant vince sulle prestazioni di ricerca filtrata. Chroma è abbastanza veloce per i prototipi ma non è costruito per la scala.

Configurazione ed esperienza dello sviluppatore

Quanto velocemente puoi andare da zero ai vettori?

Qdrant: Docker e via

Qdrant ha bisogno del suo container:

docker run -p 6333:6333 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant

Poi inserisci vettori tramite l'API REST o uno degli SDK ufficiali (Python, Rust, Go, TypeScript):

from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance

client = QdrantClient(url="http://localhost:6333")
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

La dashboard di Qdrant su localhost:6333/dashboard è un bel tocco, puoi sfogliare le collezioni, eseguire query e ispezionare i payload visivamente. Il percorso dallo sviluppo alla produzione è pulito: la tua configurazione Docker locale funziona in modo identico su un server di produzione o Qdrant Cloud.

Chroma: pip install e basta

Chroma vince la gara di semplicità con ampio margine:

import chromadb

client = chromadb.Client()  # In memoria, zero configurazione
collection = client.create_collection("documents")
collection.add(
    documents=["Il tuo documento RAG qui"],
    ids=["doc1"]
)

Nessun Docker. Nessun server. Gestisce anche automaticamente la generazione di embedding se non fornisci vettori. Per un prototipo RAG, puoi passare da pip install chromadb a una ricerca funzionante in meno di 10 righe.

Quando sei pronto per la persistenza, passa a chromadb.PersistentClient(path="./chroma_data"). Per accesso multi-processo o in rete, Chroma ha una modalità server, ma a quel punto stai iniziando a perdere il vantaggio della semplicità.

pgvector: SQL dall'inizio alla fine

Se Postgres è già nel tuo stack, pgvector è una riga sola:

CREATE EXTENSION vector;

CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

Tutto è SQL. I tuoi embedding vivono accanto ai dati della tua applicazione nella stessa transazione. Nessuna pipeline di sincronizzazione, nessuna credenziale separata, nessun servizio extra da monitorare. Se stai già eseguendo PostgreSQL in produzione, questo è il percorso di minima resistenza.

Aggiungere pgvectorscale è semplice se usi l'immagine Docker di Timescale o un provider Postgres gestito che lo supporta:

CREATE EXTENSION vectorscale;
CREATE INDEX ON documents USING diskann (embedding);

Lo svantaggio? SQL non è così ergonomico come il DSL di filtraggio dei payload di Qdrant o l'API Pythonica di Chroma. E dovrai gestire la tua pipeline di embedding, pgvector non genera embedding per te.

Verdetto: Chroma vince per il prototipo più veloce. pgvector vince se Postgres è già nel tuo stack. Qdrant ha il miglior equilibrio tra esperienza dello sviluppatore e prontezza per la produzione.

Scalabilità e prontezza per la produzione

Il prototipaggio è una cosa. Gestire una pipeline RAG che gestisce milioni di vettori con latenza costante è un'altra.

Qdrant: Costruito per scalare orizzontalmente

Qdrant supporta lo sharding orizzontale nativamente. Puoi distribuire le collezioni su più nodi, con fattori di replica configurabili per l'alta disponibilità. La sua roadmap 2026 include la segregazione lettura-scrittura e l'integrazione dello storage a blocchi per una scalabilità ancora migliore.

La multi-tenancy è una caratteristica di prima classe. Puoi partizionare i dati per tenant usando il filtraggio basato su payload senza creare collezioni separate, il che mantiene l'utilizzo delle risorse efficiente. Per i sistemi di memoria degli agenti IA che gestiscono più utenti, questo è un vantaggio significativo.

Il profilo operativo è solido: backup integrati, endpoint di metriche per Prometheus, e recupero da crash basato su WAL. Qdrant è progettato per essere self-hosted in produzione.

Chroma: Soffitto a nodo singolo

Chroma è onesto sui suoi limiti. È un database a nodo singolo focalizzato sulla semplicità e lo sviluppo locale. Nessuno sharding, nessuna replica, nessun clustering integrato.

Chroma Cloud è diventato generalmente disponibile all'inizio del 2026 come opzione gestita serverless e distribuita, ma la storia self-hosted è principalmente "un server, un'istanza Chroma." Se il tuo dataset entra in una singola macchina (fino a qualche milione di vettori a seconda della dimensionalità), va bene. Oltre a questo, incontrerai un muro.

pgvector: Scala con Postgres

pgvector eredita la storia di scalabilità collaudata di PostgreSQL. Ottieni repliche di lettura, connection pooling tramite PgBouncer, e replica logica. Provider gestiti come Neon e simili piattaforme Postgres serverless rendono la scalabilità verticale quasi senza sforzo.

L'indice StreamingDiskANN di pgvectorscale è la chiave per la scalabilità. Memorizzando l'indice del grafo su SSD invece che in RAM, puoi gestire dataset che altrimenti richiederebbero costose istanze ad alta memoria. A 50 milioni di vettori, è già competitivo con i database vettoriali dedicati.

La limitazione è lo sharding orizzontale. PostgreSQL non fa sharding nativamente come Qdrant. Soluzioni come Citus esistono ma aggiungono complessità. Per la maggior parte dei carichi di lavoro RAG self-hosted sotto 100M di vettori, la scalabilità verticale con pgvectorscale è sufficiente.

Verdetto: Qdrant vince per la scalabilità orizzontale e la multi-tenancy. pgvector vince per sfruttare l'infrastruttura Postgres esistente. Chroma non è progettato per la scala di produzione.

Costo del self-hosting

Tutti e tre sono open-source e gratuiti da eseguire. Il costo reale è l'infrastruttura e il tempo di ingegneria.

pgvector ha un vantaggio di costo strutturale: se stai già pagando per Postgres, aggiungere la ricerca vettoriale è essenzialmente gratuito finché non hai bisogno di risorse dedicate. Nessun container extra, nessun monitoraggio extra, nessuna strategia di backup extra.

L'utilizzo delle risorse di Qdrant è efficiente per il suo set di funzionalità, ma è un servizio separato, dovrai tenere conto dell'overhead operativo di gestire e monitorare un altro pezzo di infrastruttura.

Chroma è il più economico nella fase di prototipaggio (zero infrastruttura) ma diventa il percorso più costoso se provi a scalarlo oltre quello che un singolo nodo può gestire.

Per distribuire su piattaforme cloud, Qdrant e pgvector hanno entrambi distribuzioni Docker semplici. Chroma funziona anche, ma perdi la semplicità integrata che è il suo principale punto di forza.

Verdetto: pgvector vince sul costo totale di proprietà (TCO). Elimina un intero servizio dal tuo stack. Qdrant è ragionevolmente prezzato per quello che offre. La storia dei costi di Chroma funziona solo durante il prototipaggio.

Filtraggio e ricerca ibrida

RAG non è solo "trova il vettore più vicino." Devi combinare la ricerca per similarità con filtri di metadati, intervalli di date, controlli di accesso, e a volte corrispondenza di parole chiave.

Qdrant: Il re del filtraggio

Il filtraggio dei payload di Qdrant avviene durante l'attraversamento HNSW, non dopo. Questa è una distinzione critica. Il post-filtraggio può ridurre il conteggio dei tuoi risultati sotto quello che hai richiesto; il pre-filtraggio garantisce che tu ottenga k risultati che corrispondono ai tuoi vincoli.

Il DSL di filtraggio è espressivo:

from qdrant_client.models import Filter, FieldCondition, MatchValue

results = client.search(
    collection_name="documents",
    query_vector=embedding,
    query_filter=Filter(
        must=[
            FieldCondition(key="category", match=MatchValue(value="engineering")),
            FieldCondition(key="year", range=Range(gte=2024)),
        ]
    ),
    limit=10,
)

Qdrant supporta anche la ricerca ibrida nativa con vettori sia densi che sparsi nella stessa query, utile per combinare la comprensione semantica con la precisione delle parole chiave.

Chroma: Basilare ma utilizzabile

Chroma supporta il filtraggio dei metadati con clausole where:

results = collection.query(
    query_embeddings=[embedding],
    where={"category": "engineering"},
    n_results=10,
)

Funziona per casi semplici, ma il filtraggio avviene dopo la ricerca vettoriale. Con filtri restrittivi e dataset piccoli, potresti ottenere meno risultati del previsto. Non c'è supporto per vettori sparsi né ricerca ibrida integrata.

pgvector: SQL è il tuo superpotere

pgvector eredita tutta la potenza di SQL per il filtraggio:

SELECT content, embedding <=> $1 AS distance
FROM documents
WHERE category = 'engineering'
  AND created_at > '2024-01-01'
  AND content @@ to_tsquery('RAG & retrieval')
ORDER BY distance
LIMIT 10;

Quell'ultima riga combina la similarità vettoriale con la ricerca full-text integrata di PostgreSQL in una singola query. Nessun motore di ricerca esterno necessario. Puoi fare join con la tua tabella utenti per il controllo degli accessi, aggregare risultati, usare CTE, tutto quello che SQL può fare.

La scansione iterativa di pgvector 0.8.0 aiuta anche. Se la scansione HNSW iniziale non restituisce abbastanza risultati filtrati, continua automaticamente a cercare invece di restituire un set parziale.

Verdetto: Qdrant vince per il filtraggio complesso dei metadati su larga scala. pgvector vince per la flessibilità della ricerca ibrida (SQL + full-text + vettore in una query). Il filtraggio di Chroma è adeguato solo per i prototipi.

Quando usare ciascuno: Framework decisionale

Ecco la versione albero decisionale: La tua app usa già Postgres? Se sì, inizia con pgvector, puoi sempre migrare dopo se ne hai bisogno. Se no, stai prototipando o costruendo per la produzione? Il prototipo va verso Chroma. La produzione va verso Qdrant.

L'approccio "inizia semplice, migra dopo" è valido perché tutti e tre supportano formati di embedding standard. Spostare i vettori tra di loro è una migrazione dei dati, non una riscrittura dell'architettura.

Il fattore pgvectorscale: Perché Postgres sta recuperando

Vale la pena soffermarsi qui perché cambia il calcolo per molti team.

Prima di pgvectorscale, la critica a pgvector era sempre "funziona bene sotto un milione di vettori, ma non scala." Era vero. Gli indici HNSW vivono interamente in RAM, e una volta che il tuo dataset supera la memoria disponibile, le prestazioni crollano.

StreamingDiskANN cambia l'equazione. Memorizzando l'indice del grafo su SSD invece che in RAM, pgvectorscale gestisce 50 milioni di vettori a 471 QPS con il 99% di recall. La Quantizzazione Binaria Statistica (SBQ) comprime i vettori con perdita di precisione minima, il recall scende dal 98,6% al 96,5% anche con compressione aggressiva.

L'impatto pratico: un team che gestisce una pipeline RAG su Postgres non ha più bisogno di pianificare una migrazione a un database vettoriale dedicato "quando le cose diventano serie." Per molti carichi di lavoro, pgvector + pgvectorscale è l'opzione seria.

Detto questo, pgvectorscale non è una panacea. È un'estensione di TigerData (ex Timescale), quindi hai bisogno della loro immagine Docker o di un provider che la includa. Una release del 2026 ha aggiunto la ricerca vettoriale filtrata per etichette a StreamingDiskANN (ispirata alla ricerca Filtered DiskANN di Microsoft), riducendo il vantaggio storico di Qdrant sulle query filtrate. Ma se hai bisogno di isolamento multi-tenant o di supporto nativo per i vettori sparsi, Qdrant ha ancora il vantaggio.

Come Techsy approccia la selezione del database vettoriale

Quando costruiamo pipeline RAG per i clienti, il nostro processo di valutazione è così:

1. Audit dello stack esistente. Se il team esegue già Postgres, pgvector è il punto di partenza predefinito. Non ha senso aggiungere complessità infrastrutturale senza una ragione chiara.
2. Profilazione dei pattern di query. Filtraggio intensivo dei metadati con campi ad alta cardinalità? Questo spinge verso Qdrant. Ricerca semantica semplice? pgvector o Chroma vanno bene.
3. Stima della traiettoria di scala. Sotto 5M di vettori e rimanendo lì? Qualsiasi opzione funziona. Pianificando 50M+? pgvectorscale o Qdrant, a seconda del punto 2.
4. Verifica della capacità ops del team. Una startup di due persone non dovrebbe gestire un cluster Qdrant. Un provider Postgres gestito con pgvector è di solito la scelta giusta.

Abbiamo costruito sistemi RAG di produzione con tutti e tre. La risposta onesta è che la scelta del database conta meno della tua strategia di chunking, del modello di embedding, e della progettazione della pipeline di recupero. Se stai spendendo più tempo a dibattere su Qdrant vs pgvector che a testare diverse dimensioni di chunk, stai ottimizzando la cosa sbagliata.

Hai bisogno di aiuto per progettare una pipeline RAG? La scelta del vector store e la progettazione del recupero fanno parte del nostro servizio di integrazione AI. Contattaci e ti aiuteremo a scegliere la base giusta e a costruire il layer attorno ad essa.

Domande frequenti

pgvector è abbastanza buono per RAG in produzione?

Sì, specialmente con pgvectorscale. L'indice StreamingDiskANN gestisce 50M+ di vettori con il 99% di recall a livelli di throughput che battono i database vettoriali dedicati nei benchmark. Se esegui già Postgres, raramente c'è una ragione per aggiungere un database vettoriale separato per RAG.

Chroma può scalare a milioni di vettori?

Chroma può gestire qualche milione di vettori su un singolo nodo con abbastanza RAM, ma non ha scalabilità orizzontale integrata. Per dataset oltre quello che una singola macchina può contenere, dovrai migrare a Qdrant, pgvector, o un servizio gestito.

Qdrant supporta la ricerca ibrida con parole chiave?

Sì. Qdrant supporta vettori sia densi che sparsi nella stessa collezione. Puoi eseguire query ibride che combinano similarità semantica (denso) con corrispondenza di parole chiave (sparso) e controllare la ponderazione tra loro.

Quanta RAM ho bisogno per ogni database?

Dipende dal conteggio dei vettori e dalle dimensioni. Come guida approssimativa: 1M di vettori a 1536 dimensioni occupa circa 6 GB in Qdrant o pgvector con HNSW. Chroma usa leggermente di più a causa dell'overhead Python. L'indice DiskANN di pgvectorscale riduce drasticamente i requisiti di RAM memorizzando l'indice su SSD.

Posso migrare tra questi database in seguito?

Sì. Tutti e tre lavorano con array float standard, quindi i vettori sono portabili. Dovrai ricreare gli indici e adattare il tuo layer di query, ma è una migrazione dei dati, non una riscrittura. La maggior parte degli strumenti di migrazione come lo strumento di migrazione ufficiale di Qdrant semplificano questo.

Quale funziona meglio con LangChain e LlamaIndex?

Tutti e tre hanno integrazioni ufficiali con LangChain e LlamaIndex. Chroma è spesso il predefinito nei tutorial, rendendolo il più fluido per iniziare. Le integrazioni di Qdrant e pgvector sono ugualmente mature per l'uso in produzione. Consulta la nostra guida sui migliori strumenti RAG per una visione più ampia dell'ecosistema.

Dovrei usare pgvector o pgvectorscale?

Usa entrambi. pgvector fornisce il tipo vector di base e l'indice HNSW. pgvectorscale aggiunge StreamingDiskANN sopra per prestazioni migliori su larga scala. Sono estensioni complementari, non alternative.

Qdrant è gratuito per il self-hosting?

Completamente gratuito sotto la licenza Apache 2.0. Qdrant Cloud è l'opzione gestita a pagamento, che inizia con un livello gratuito da 1 GB. Per il self-hosting, paghi solo per l'infrastruttura di calcolo.

Che dire di Milvus o Weaviate?

Entrambi sono alternative solide. Milvus è più forte a scala molto grande (miliardi+ di vettori) con accelerazione GPU. Weaviate ha un buon pipeline di vettorizzazione integrato. Ma per RAG self-hosted sotto 100M di vettori, Qdrant, Chroma e pgvector coprono la grande maggioranza dei casi d'uso con meno complessità operativa.

pgvector può gestire query RAG concorrenti in produzione?

Sì. PostgreSQL è progettato per carichi di lavoro concorrenti. pgvector eredita il connection pooling (PgBouncer), le repliche di lettura, e il controllo della concorrenza MVCC. Per RAG ad alto throughput, abbina pgvector a un connection pooler e ottimizza shared_buffers e effective_cache_size.

Verdetto finale

In generale: Per la maggior parte delle pipeline RAG self-hosted, pgvector + pgvectorscale è la scelta pragmatica. È abbastanza veloce, scala a decine di milioni di vettori, e mantiene il tuo stack semplice. Conosci già SQL. Il tuo team gestisce già Postgres. Un servizio in meno significa una cosa in meno che può rompersi alle 2 di notte.

Se hai bisogno di ricerca filtrata avanzata, multi-tenancy, o stai costruendo un prodotto dove la ricerca vettoriale è la caratteristica principale (non una capacità di supporto), Qdrant è l'investimento giusto. È il database vettoriale open-source più completo per una ragione.

Chroma merita il suo posto come strumento di prototipaggio. Usalo per validare il tuo approccio RAG, testare diverse strategie di chunking e iterare sulla qualità del recupero. Quando sei pronto per la produzione, migra a qualunque degli altri due si adatti al tuo stack.

Il miglior consiglio? Smettila di dibattere e inizia a costruire. Scegli pgvector se hai Postgres, Qdrant se non ce l'hai, e metti in funzione la tua pipeline RAG. Puoi sempre cambiare il vector store in seguito, il modello di embedding, la strategia di chunking e la logica di recupero contano molto di più.

Fonti

• Qdrant Benchmarks
• Chroma 1.0 Release: 4x Faster
• pgvectorscale: StreamingDiskANN for PostgreSQL
• pgvector Is Now Faster than Pinecone at 75% Less Cost
• pgvector 0.8.0: Iterative Index Scanning
• Qdrant Pricing