Qdrant vs Chroma vs pgvector : Choisir la bonne base de données vectorielle pour RAG auto-hébergé

Qdrant vs Chroma vs pgvector : Choisir la bonne base de données vectorielle pour RAG auto-hébergé

Le choix Qdrant vs Chroma vs pgvector se résume à un compromis à trois voies : vitesse dédiée, simplicité pour les prototypes, ou rester dans l'écosystème Postgres. Chaque approche fonctionne, la question est quel compromis correspond à votre pipeline RAG.

Résumé rapide : Quelle base de données vectorielle choisir ?

Choisissez Qdrant si vous avez besoin d'une recherche vectorielle de niveau production avec un filtrage avancé, la multi-location, et que vous acceptez de faire tourner un service séparé.

Choisissez Chroma si vous faites du prototypage, voulez un développement local sans configuration, ou avez besoin de passer d'une idée à un RAG fonctionnel en moins d'une heure.

Choisissez pgvector (+ pgvectorscale) si vous utilisez déjà PostgreSQL et voulez la recherche vectorielle sans ajouter d'infrastructure, surtout maintenant que l'index StreamingDiskANN de pgvectorscale a comblé l'écart de performances.

Si vous construisez une application RAG de zéro, la suite de cet article vous aidera à choisir la bonne fondation.

Performance : Quelle base de données est la plus rapide ?

La performance est importante dès que vous dépassez quelques milliers de documents. Voici où ces trois divergent significativement.

Qdrant

Qdrant est conçu de A à Z pour la recherche vectorielle. Son implémentation en Rust et son index HNSW personnalisé offrent une latence constamment faible, les benchmarks montrent une latence de requête d'environ 94 ms même sous charge simultanée. Il prend en charge la quantification scalaire, binaire et par produit pour compresser les vecteurs et accélérer la recherche tout en maintenant le recall au-dessus de 95 %.

Qdrant brille vraiment dans la recherche filtrée. Contrairement aux bases de données qui trouvent d'abord les voisins les plus proches puis filtrent, le HNSW filtrable de Qdrant respecte les contraintes de métadonnées pendant le parcours du graphe. Cela signifie que vous ne perdez pas de recall en combinant la recherche vectorielle avec des filtres comme category = "technical" ou date > 2025-01-01.

Chroma

La version 1.0 de Chroma a réécrit le noyau en Rust, offrant des lectures et écritures 3 à 5 fois plus rapides par rapport à l'implémentation Python d'origine. Une mise à jour en août 2025 a ajouté l'encodage base64 des vecteurs pour un gain supplémentaire de 70 % de débit.

Pour les jeux de données sous un million de vecteurs, Chroma est véritablement rapide. Il s'exécute intégré dans votre processus Python sans surcharge réseau, ce qui rend l'itération locale réactive. Mais c'est une base de données à nœud unique, pas de sharding ni de réplication intégrés.

pgvector + pgvectorscale

C'est l'outsider. Le pgvector standard avec HNSW est 5 250 fois plus rapide qu'un scan séquentiel, et pgvector 0.8.0 a ajouté l'analyse itérative d'index pour résoudre le problème de sur-filtrage qui affectait les versions antérieures.

Mais la vraie histoire est pgvectorscale. L'extension de Timescale ajoute l'index StreamingDiskANN, inspiré de la recherche DiskANN de Microsoft, qui stocke l'index sur disque plutôt qu'en RAM. Sur un benchmark de 50 millions d'embeddings Cohere (768 dimensions), pgvectorscale a atteint 471 QPS à 99 % de recall. C'est un débit 11,4 fois supérieur aux 41 QPS de Qdrant au même niveau de recall, et une latence p95 28 fois inférieure à l'index optimisé pour le stockage de Pinecone.

Le bémol ? Ces benchmarks ont utilisé une instance EC2 puissante. Vos résultats dépendent du matériel. Mais la tendance est claire : PostgreSQL n'est plus l'option « suffisamment bonne » pour la recherche vectorielle, elle est véritablement compétitive.

Verdict : pgvector + pgvectorscale gagne sur les chiffres bruts des benchmarks. Qdrant gagne sur les performances de recherche filtrée. Chroma est assez rapide pour les prototypes mais n'est pas conçu pour la mise à l'échelle.

Installation et expérience développeur

À quelle vitesse pouvez-vous aller de zéro à des vecteurs ?

Qdrant : Docker et c'est parti

Qdrant a besoin de son propre conteneur :

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

Ensuite, insérez des vecteurs via l'API REST ou l'un des SDK officiels (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),
)

Le tableau de bord de Qdrant sur localhost:6333/dashboard est un bel ajout, vous pouvez parcourir les collections, exécuter des requêtes et inspecter les payloads visuellement. Le chemin de dev vers la production est propre : votre configuration Docker locale fonctionne identiquement sur un serveur de production ou Qdrant Cloud.

Chroma : pip install et c'est tout

Chroma gagne la course à la simplicité haut la main :

import chromadb

client = chromadb.Client()  # En mémoire, zéro config
collection = client.create_collection("documents")
collection.add(
    documents=["Votre document RAG ici"],
    ids=["doc1"]
)

Pas de Docker. Pas de serveur. Il gère même automatiquement la génération d'embeddings si vous ne fournissez pas de vecteurs. Pour un prototype RAG, vous pouvez passer de pip install chromadb à une recherche fonctionnelle en moins de 10 lignes.

Quand vous êtes prêt pour la persistance, passez à chromadb.PersistentClient(path="./chroma_data"). Pour l'accès multi-processus ou en réseau, Chroma a un mode serveur, mais à ce stade, vous commencez à perdre l'avantage de simplicité.

pgvector : SQL de bout en bout

Si Postgres est déjà dans votre stack, pgvector est une seule ligne :

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);

Tout est SQL. Vos embeddings vivent à côté de vos données d'application dans la même transaction. Pas de pipeline de synchronisation, pas d'identifiants séparés, pas de service supplémentaire à surveiller. Si vous faites déjà tourner PostgreSQL en production, c'est la voie de moindre résistance.

Ajouter pgvectorscale par-dessus est simple si vous utilisez l'image Docker de Timescale ou un fournisseur Postgres géré qui le prend en charge :

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

L'inconvénient ? SQL n'est pas aussi ergonomique que le DSL de filtrage des payloads de Qdrant ou l'API Pythonique de Chroma. Et vous devrez gérer votre propre pipeline d'embeddings, pgvector ne génère pas d'embeddings pour vous.

Verdict : Chroma gagne pour le prototype le plus rapide. pgvector gagne si Postgres est déjà dans votre stack. Qdrant offre le meilleur équilibre entre expérience développeur et maturité pour la production.

Mise à l'échelle et maturité pour la production

Le prototypage est une chose. Faire tourner un pipeline RAG qui gère des millions de vecteurs avec une latence constante en est une autre.

Qdrant : Conçu pour la mise à l'échelle horizontale

Qdrant prend en charge le sharding horizontal nativement. Vous pouvez distribuer les collections sur plusieurs nœuds, avec des facteurs de réplication configurables pour la haute disponibilité. Sa feuille de route 2026 inclut la ségrégation lecture-écriture et l'intégration du stockage en blocs pour une mise à l'échelle encore meilleure.

La multi-location est une fonctionnalité de premier plan. Vous pouvez partitionner les données par locataire en utilisant le filtrage basé sur le payload sans créer de collections séparées, ce qui maintient l'utilisation des ressources efficace. Pour les systèmes de mémoire d'agents IA gérant plusieurs utilisateurs, c'est un avantage significatif.

L'aspect opérationnel est solide : sauvegardes intégrées, points de terminaison de métriques pour Prometheus, et récupération après crash basée sur WAL. Qdrant est conçu pour être auto-hébergé en production.

Chroma : Plafond à nœud unique

Chroma est honnête sur ses limites. C'est une base de données à nœud unique axée sur la simplicité et le développement local. Pas de sharding intégré, pas de réplication, pas de clustering.

Chroma Cloud est devenu généralement disponible début 2026 comme option gérée serverless et distribuée, mais l'histoire auto-hébergée est principalement « un serveur, une instance Chroma. » Si votre jeu de données tient sur une seule machine (jusqu'à quelques millions de vecteurs selon la dimensionnalité), c'est bien. Au-delà, vous vous heurterez à un mur.

pgvector : Évolue avec Postgres

pgvector hérite de l'histoire de mise à l'échelle éprouvée de PostgreSQL. Vous obtenez des réplicas en lecture, la mise en pool de connexions via PgBouncer, et la réplication logique. Les fournisseurs gérés comme Neon et des plateformes Postgres serverless similaires rendent la mise à l'échelle verticale presque sans effort.

L'index StreamingDiskANN de pgvectorscale est la clé pour la mise à l'échelle. En stockant l'index de graphe sur SSD plutôt qu'en RAM, vous pouvez gérer des jeux de données qui nécessiteraient sinon des instances coûteuses à forte mémoire. À 50 millions de vecteurs, il est déjà compétitif avec les bases de données vectorielles dédiées.

La limitation est le sharding horizontal. PostgreSQL ne sharde pas nativement comme Qdrant. Des solutions comme Citus existent mais ajoutent de la complexité. Pour la plupart des charges de travail RAG auto-hébergées sous 100M de vecteurs, la mise à l'échelle verticale avec pgvectorscale est suffisante.

Verdict : Qdrant gagne pour la mise à l'échelle horizontale et la multi-location. pgvector gagne pour exploiter l'infrastructure Postgres existante. Chroma n'est pas conçu pour la mise à l'échelle en production.

Coût de l'auto-hébergement

Les trois sont open-source et gratuits à faire tourner. Le coût réel est l'infrastructure et le temps d'ingénierie.

pgvector a un avantage de coût structurel : si vous payez déjà pour Postgres, ajouter la recherche vectorielle est essentiellement gratuit jusqu'à ce que vous ayez besoin de ressources dédiées. Pas de conteneur supplémentaire, pas de surveillance supplémentaire, pas de stratégie de sauvegarde supplémentaire.

L'utilisation des ressources de Qdrant est efficace pour son ensemble de fonctionnalités, mais c'est un service séparé, vous devrez tenir compte de la surcharge opérationnelle de faire tourner et surveiller une autre infrastructure.

Chroma est le moins cher au stade du prototype (zéro infrastructure) mais devient le chemin le plus coûteux si vous essayez de le faire évoluer au-delà de ce qu'un seul nœud peut gérer.

Pour déployer sur des plateformes cloud, Qdrant et pgvector ont tous deux des déploiements Docker simples. Chroma fonctionne aussi, mais vous perdez la simplicité intégrée qui est son principal argument de vente.

Verdict : pgvector gagne sur le coût total de possession. Il élimine un service entier de votre stack. Qdrant est raisonnablement tarifé pour ce qu'il offre. L'histoire de coût de Chroma ne fonctionne que pendant le prototypage.

Filtrage et recherche hybride

RAG ne consiste pas seulement à « trouver le vecteur le plus proche. » Vous devez combiner la recherche par similarité avec des filtres de métadonnées, des plages de dates, des contrôles d'accès, et parfois la correspondance par mots-clés.

Qdrant : Le roi du filtrage

Le filtrage des payloads de Qdrant se produit pendant le parcours HNSW, pas après. C'est une distinction critique. Le post-filtrage peut réduire votre nombre de résultats en dessous de ce que vous avez demandé ; le pré-filtrage garantit que vous obtenez k résultats correspondant à vos contraintes.

Le DSL de filtrage est expressif :

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 prend également en charge la recherche hybride native avec des vecteurs denses et épars dans la même requête, ce qui est utile pour combiner la compréhension sémantique avec la précision des mots-clés.

Chroma : Basique mais utilisable

Chroma prend en charge le filtrage des métadonnées avec des clauses where :

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

Cela fonctionne pour les cas simples, mais le filtrage se produit après la recherche vectorielle. Avec des filtres restrictifs et des petits jeux de données, vous pourriez obtenir moins de résultats qu'attendu. Il n'y a pas de prise en charge des vecteurs épars ni de recherche hybride intégrée.

pgvector : SQL est votre superpouvoir

pgvector hérite de toute la puissance de SQL pour le filtrage :

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;

Cette dernière ligne combine la similarité vectorielle avec la recherche en texte intégral intégrée de PostgreSQL dans une seule requête. Pas de moteur de recherche externe nécessaire. Vous pouvez faire des jointures avec votre table d'utilisateurs pour le contrôle d'accès, agréger les résultats, utiliser des CTE, tout ce que SQL peut faire.

L'analyse itérative de pgvector 0.8.0 aide également. Si le scan HNSW initial ne renvoie pas assez de résultats filtrés, il continue automatiquement la recherche plutôt que de retourner un ensemble partiel.

Verdict : Qdrant gagne pour le filtrage complexe de métadonnées à grande échelle. pgvector gagne pour la flexibilité de la recherche hybride (SQL + texte intégral + vecteur dans une requête). Le filtrage de Chroma n'est adéquat que pour les prototypes.

Quand utiliser chaque option : Cadre de décision

Voici la version arbre de décision : Votre application utilise-t-elle déjà Postgres ? Si oui, commencez avec pgvector, vous pourrez toujours migrer plus tard si vous en avez besoin. Si non, est-ce un prototype ou une construction pour la production ? Prototype va vers Chroma. Production va vers Qdrant.

L'approche « commencer simple, migrer plus tard » est valide parce que les trois prennent en charge les formats d'embeddings standard. Déplacer des vecteurs entre eux est une migration de données, pas une réécriture d'architecture.

Le facteur pgvectorscale : Pourquoi Postgres rattrape son retard

Cela vaut la peine d'y dweller car cela change le calcul pour beaucoup d'équipes.

Avant pgvectorscale, le reproche sur pgvector était toujours « ça fonctionne bien sous un million de vecteurs, mais ça ne met pas à l'échelle. » C'était vrai. Les index HNSW vivent entièrement en RAM, et une fois que votre jeu de données dépasse la mémoire disponible, les performances s'effondrent.

StreamingDiskANN change l'équation. En stockant l'index de graphe sur SSD plutôt qu'en RAM, pgvectorscale gère 50 millions de vecteurs à 471 QPS avec 99 % de recall. La Quantification Binaire Statistique (SBQ) compresse les vecteurs avec une perte de précision minimale, le recall passe de 98,6 % à 96,5 % même avec une compression agressive.

L'impact pratique : une équipe faisant tourner un pipeline RAG sur Postgres n'a plus besoin de planifier une migration vers une base de données vectorielle dédiée « quand les choses deviennent sérieuses. » Pour de nombreuses charges de travail, pgvector + pgvectorscale est l'option sérieuse.

Cela dit, pgvectorscale n'est pas une solution miracle. C'est une extension de TigerData (anciennement Timescale), donc vous avez besoin soit de leur image Docker, soit d'un fournisseur qui l'intègre. Une version de 2026 a ajouté la recherche vectorielle filtrée par labels à StreamingDiskANN (inspirée de la recherche Filtered DiskANN de Microsoft), ce qui réduit l'avance de longue date de Qdrant sur les requêtes filtrées. Mais si vous avez besoin d'isolation multi-locataire ou de prise en charge native des vecteurs épars, Qdrant garde l'avantage.

Comment Techsy aborde la sélection de base de données vectorielle

Quand nous construisons des pipelines RAG pour nos clients, notre processus d'évaluation ressemble à ceci :

1. Auditer le stack existant. Si l'équipe fait déjà tourner Postgres, pgvector est le point de départ par défaut. Pas la peine d'ajouter de la complexité d'infrastructure sans raison claire.
2. Profiler les patterns de requête. Filtrage de métadonnées intensif avec des champs à haute cardinalité ? Cela pousse vers Qdrant. Recherche sémantique simple ? pgvector ou Chroma convient.
3. Estimer la trajectoire de mise à l'échelle. Sous 5 M de vecteurs et y restant ? N'importe quelle option fonctionne. Planification pour 50 M+ ? pgvectorscale ou Qdrant, selon l'étape 2.
4. Vérifier la capacité ops de l'équipe. Une startup de deux personnes ne devrait pas gérer un cluster Qdrant. Un fournisseur Postgres géré avec pgvector est généralement le bon choix.

Nous avons construit des systèmes RAG de production avec les trois. La réponse honnête est que le choix de la base de données importe moins que votre stratégie de découpage, le modèle d'embedding, et la conception du pipeline de récupération. Si vous passez plus de temps à débattre de Qdrant vs pgvector qu'à tester différentes tailles de morceaux, vous optimisez la mauvaise chose.

Besoin d'aide pour concevoir un pipeline RAG ? La sélection du vector store et la conception de la récupération font partie de notre service d'intégration IA. Contactez-nous et nous vous aiderons à choisir la bonne base et à construire la couche autour.

Foire aux questions

pgvector est-il suffisamment bon pour un RAG en production ?

Oui, surtout avec pgvectorscale. L'index StreamingDiskANN gère 50 M+ de vecteurs avec 99 % de recall à des niveaux de débit qui battent les bases de données vectorielles dédiées dans les benchmarks. Si vous faites déjà tourner Postgres, il y a rarement une raison d'ajouter une base de données vectorielle séparée pour RAG.

Chroma peut-il évoluer à des millions de vecteurs ?

Chroma peut gérer quelques millions de vecteurs sur un seul nœud avec suffisamment de RAM, mais il n'a pas de mise à l'échelle horizontale intégrée. Pour des jeux de données au-delà de ce qu'une seule machine peut contenir, vous devrez migrer vers Qdrant, pgvector, ou un service géré.

Qdrant prend-il en charge la recherche hybride avec des mots-clés ?

Oui. Qdrant prend en charge les vecteurs denses et épars dans la même collection. Vous pouvez exécuter des requêtes hybrides qui combinent la similarité sémantique (dense) avec la correspondance de mots-clés (éparse) et contrôler la pondération entre eux.

De combien de RAM ai-je besoin pour chaque base de données ?

Cela dépend du nombre de vecteurs et des dimensions. En guide approximatif : 1 M de vecteurs à 1 536 dimensions prend environ 6 Go dans Qdrant ou pgvector avec HNSW. Chroma utilise légèrement plus en raison de la surcharge Python. L'index DiskANN de pgvectorscale réduit considérablement les besoins en RAM en stockant l'index sur SSD.

Puis-je migrer entre ces bases de données plus tard ?

Oui. Les trois fonctionnent avec des tableaux float standard, donc les vecteurs sont portables. Vous devrez recréer les index et adapter votre couche de requête, mais c'est une migration de données, pas une réécriture. La plupart des outils de migration comme l'outil de migration officiel de Qdrant simplifient cela.

Lequel fonctionne le mieux avec LangChain et LlamaIndex ?

Les trois ont des intégrations officielles avec LangChain et LlamaIndex. Chroma est souvent la valeur par défaut dans les tutoriels, ce qui en fait le plus fluide pour débuter. Les intégrations Qdrant et pgvector sont également matures pour un usage en production. Consultez notre guide sur les meilleurs outils RAG pour un aperçu plus large de l'écosystème.

Devrais-je utiliser pgvector ou pgvectorscale ?

Utilisez les deux. pgvector fournit le type vector de base et l'index HNSW. pgvectorscale ajoute StreamingDiskANN par-dessus pour de meilleures performances à grande échelle. Ce sont des extensions complémentaires, pas des alternatives.

Qdrant est-il gratuit à auto-héberger ?

Complètement gratuit sous la licence Apache 2.0. Qdrant Cloud est l'option gérée payante, commençant par un niveau gratuit de 1 Go. Pour l'auto-hébergement, vous ne payez que pour l'infrastructure de calcul.

Qu'en est-il de Milvus ou Weaviate à la place ?

Les deux sont des alternatives solides. Milvus est plus fort à très grande échelle (milliards+ de vecteurs) avec accélération GPU. Weaviate a un bon pipeline de vectorisation intégré. Mais pour le RAG auto-hébergé sous 100 M de vecteurs, Qdrant, Chroma et pgvector couvrent la grande majorité des cas d'utilisation avec moins de complexité opérationnelle.

pgvector peut-il gérer des requêtes RAG simultanées en production ?

Oui. PostgreSQL est conçu pour les charges de travail simultanées. pgvector hérite de la mise en pool de connexions (PgBouncer), des réplicas en lecture, et du contrôle de concurrence MVCC. Pour un RAG à haut débit, associez pgvector à un pooler de connexions et ajustez shared_buffers et effective_cache_size.

Verdict final

En résumé : Pour la plupart des pipelines RAG auto-hébergés, pgvector + pgvectorscale est le choix pragmatique. C'est suffisamment rapide, ça monte à des dizaines de millions de vecteurs, et ça garde votre stack simple. Vous connaissez déjà SQL. Votre équipe gère déjà Postgres. Un service en moins signifie une chose en moins qui peut tomber en panne à 2 h du matin.

Si vous avez besoin d'une recherche filtrée avancée, de la multi-location, ou si vous construisez un produit où la recherche vectorielle est la fonctionnalité principale (pas une capacité de support), Qdrant est le bon investissement. C'est la base de données vectorielle open-source la plus complète pour une raison.

Chroma mérite sa place comme outil de prototypage. Utilisez-le pour valider votre approche RAG, tester différentes stratégies de découpage, et itérer sur la qualité de récupération. Quand vous êtes prêt pour la production, migrez vers celle des deux autres qui correspond à votre stack.

Le meilleur conseil ? Arrêtez de débattre et commencez à construire. Choisissez pgvector si vous avez Postgres, Qdrant si vous n'en avez pas, et mettez votre pipeline RAG en marche. Vous pourrez toujours changer le vector store plus tard, le modèle d'embedding, la stratégie de découpage et la logique de récupération comptent bien plus.

Sources

• 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