Le choix de la base vectorielle est débattu sans fin en ligne, mais pour la plupart des projets il compte bien moins que la stratégie de chunking et de retrieval. Malgré tout, se tromper signifie du travail d'infrastructure inutile ou une migration coûteuse plus tard. En 2026, les quatre choix les plus courants sont Chroma (aussi appelé ChromaDB), Qdrant, Pinecone et pgvector. D'autres existent, Weaviate, Milvus, LanceDB, turbopuffer, mais ces quatre couvrent la grande majorité des projets RAG. Voici ce qui différencie vraiment ces solutions.

Les bases vectorielles en un coup d'oeil

Lisez ce tableau comme un outil de présélection, pas comme un verdict. Chaque ligne ne compte que dans un contexte précis, et les sections suivantes expliquent lequel.

Chroma : le point de départ le plus simple

Chroma, aussi appelé ChromaDB, tourne en embarqué dans votre processus Python ou comme serveur local léger. Il n'y a aucune infrastructure à monter, ce qui en fait le moyen le plus rapide de faire fonctionner un prototype RAG et un bon choix pour les jeux de données petits à moyens. Il persiste sur disque, expose une API de collections simple, et s'intègre nativement à LangChain et LlamaIndex. Ce qu'il n'a pas, c'est une histoire de scaling distribué : pas de clustering natif, une concurrence limitée sous forte charge d'écriture, et un filtrage de métadonnées fonctionnel mais basique. Ce n'est rarement un problème jusqu'à ce que ça le devienne, en général autour du million de vecteurs ou quand plusieurs services l'interrogent en même temps.

• ✓Forces : pas d'infra, démarrage rapide, bonne expérience développeur en local, intégrations de frameworks natives.
• ✓Limites : mono-noeud, filtrage basique, faible sous écritures concurrentes, pas conçu pour le scale horizontal.

Qdrant : filtrage de niveau production, auto-hébergé

Qdrant est un moteur open source écrit en Rust. Vous l'auto-hébergez ou utilisez Qdrant Cloud, et il est fait pour le cas où la similarité vectorielle seule ne suffit pas. Son index HNSW filter-aware combine la similarité avec des conditions structurées, plages de dates, catégories, identifiants de tenant, permissions, efficacement et à l'échelle, plutôt que de filtrer avant ou après la recherche et d'en payer le prix. Il supporte la quantization scalaire, produit et binaire pour réduire la mémoire, les vecteurs dense et sparse pour la recherche hybride, et un mode distribué avec sharding et réplication. Le coût, c'est que vous l'opérez, ou payez le palier managé.

• ✓Forces : recherche filtrée puissante, quantization, recherche hybride, mode distribué, large couverture SDK.
• ✓Limites : vous gérez l'infrastructure, ou passez au palier cloud payant ; plus de pièces mobiles qu'un store embarqué.

Pinecone : entièrement managé, zéro ops

Pinecone est un SaaS managé sans option d'auto-hébergement. Ses index serverless font évoluer le stockage et la capacité de requête sans que l'équipe ne touche à un serveur, et la latence reste prévisible quand les données grossissent. Les compromis sont réels : la tarification est à l'usage et croît avec le volume et le taux de requêtes, vous avez moins de contrôle sur la configuration de l'index, et vos vecteurs vivent chez un seul fournisseur. Pour une équipe sans capacité ops et avec un budget qui colle à la tarification, c'est souvent un compromis acceptable.

• ✓Forces : pas d'ops, latence prévisible à l'échelle, capacité serverless, adoption rapide.
• ✓Limites : pas d'auto-hébergement, coût à l'usage qui croît, dépendance fournisseur, moins de maîtrise de l'index.

pgvector : quand Postgres tourne déjà

pgvector ajoute la recherche vectorielle à une base Postgres existante sous forme d'extension. Il n'y a aucune nouvelle brique d'infrastructure à opérer, et vous filtrez avec de simples clauses WHERE SQL et joignez une recherche par similarité à vos données relationnelles en une seule requête, avec une cohérence transactionnelle complète. Les versions récentes supportent les index HNSW et IVFFlat ainsi qu'un type de vecteur demi-précision pour économiser de l'espace. À très grand volume de vecteurs ou fort taux de requêtes, les moteurs dédiés le surpassent encore, et pgvectorscale de Timescale repousse ce plafond. Pour des jeux de données modérés, il retire une pièce mobile entière de la stack.

-- pgvector : recherche par similarité + filtre métadonnées + jointure, une seule requête
SELECT d.id, d.title, d.content, a.name AS author
FROM documents d
JOIN authors a ON a.id = d.author_id
WHERE d.tenant_id = $1
  AND d.published_at >= now() - interval '90 days'
ORDER BY d.embedding <=> $2
LIMIT 5;

• ✓Forces : pas d'infra supplémentaire, filtrage SQL, jointures avec les données relationnelles, écritures transactionnelles, un seul datastore à sauvegarder.
• ✓Limites : plus lent que les moteurs dédiés au-delà de quelques millions de vecteurs, coût de construction d'index et de RAM, le tuning est à votre charge.

Chroma ou pgvector pour démarrer ?

Ce sont les deux façons courantes de commencer. Choisissez pgvector si Postgres tourne déjà et que vous voulez un seul datastore, du filtrage SQL et des écritures transactionnelles à côté de vos données applicatives. Choisissez Chroma pour un prototype pur Python où vous ne voulez pas gérer de base du tout. Aucun des deux n'est le point d'arrivée si vous montez à des dizaines de millions de vecteurs sous charge, mais les deux suffisent largement pour livrer une première version et apprendre ce dont votre retrieval a réellement besoin.

Performance et scalabilité

Ce qui détermine la performance de la recherche vectorielle, ce n'est le plus souvent pas la marque. C'est le type d'index et ses paramètres (ef_construction et M pour HNSW), la quantization, la sélectivité de vos filtres de métadonnées, la taille du jeu de données et la cible de rappel que vous acceptez. Directionnellement : les moteurs dédiés comme Qdrant et Pinecone prennent l'avantage au-delà de quelques millions de vecteurs et sous charge concurrente, tandis que Chroma et pgvector simple conviennent jusqu'à environ un million de vecteurs à des taux de requêtes RAG typiques. Les benchmarks publics varient énormément selon la configuration, traitez-les comme une direction et mesurez avec vos propres données, votre cible de rappel et vos motifs de filtrage.

• ✓Taille du jeu de données et rythme de croissance.
• ✓Rappel@k au k choisi, pas seulement la vitesse brute.
• ✓Latence p95, filtrée et non filtrée, car le filtrage change le coût.
• ✓Débit d'ingestion et temps de construction de l'index.
• ✓Empreinte mémoire de l'index, avec et sans quantization.

Filtrage et recherche hybride

Le filtrage de métadonnées est souvent là où la qualité du RAG se gagne ou se perd : isolation multi-tenant, fraîcheur, type de document, contrôle d'accès. La question est de savoir si la base filtre pendant la recherche ou avant et après, ce qui change à la fois la précision et la vitesse. Qdrant, Pinecone et pgvector gèrent bien la recherche filtrée, Chroma est plus limité. La recherche hybride, combiner des vecteurs dense avec un signal de mots-clés sparse comme BM25 ou SPLADE, est intégrée à Qdrant, disponible dans Pinecone et possible avec pgvector via des extensions. Elle compte surtout quand des termes exacts, noms, codes, chaînes d'erreur, doivent se classer aux côtés des correspondances sémantiques.

Coût

• ✓Chroma : l'infrastructure sur laquelle vous le faites tourner, quasi nul pour un usage local ou mono-instance modeste.
• ✓Qdrant : le compute auto-hébergé que vous provisionnez, ou les paliers Qdrant Cloud facturés sur la mémoire et le stockage.
• ✓Pinecone : à l'usage, facturé sur le stockage plus des unités de lecture et d'écriture, prévisible en exploitation mais croissant avec l'échelle.
• ✓pgvector : un coût marginal sur une base que vous payez déjà, principalement le stockage et la RAM dont l'index a besoin.

Migration entre bases

Les vecteurs sont portables. Tant que vous gardez le même modèle d'embedding, vous ne re-embeddez rien pour changer de base. Ce qui change, c'est l'API client, la syntaxe des filtres, la configuration de l'index et le schéma de métadonnées. Si un changement est plausible, gardez le vector store derrière une interface, l'abstraction vectorstore de LangChain ou LlamaIndex suffit, pour que le changement reste au même endroit. Vous ne re-embeddez que lorsque vous changez le modèle d'embedding lui-même, ce qui est une décision distincte et plus lourde.

Grille de décision

• ✓Prototypage ou petit jeu de données : Chroma.
• ✓Postgres déjà en place, échelle modérée : pgvector.
• ✓Auto-hébergé avec du filtrage de métadonnées lourd : Qdrant.
• ✓Pas d'équipe ops et un budget qui colle : Pinecone.
• ✓Dizaines de millions de vecteurs à fort taux de requêtes : Qdrant, Pinecone ou pgvector avec pgvectorscale.

FAQ

Chroma ou Qdrant ?

Chroma pour le démarrage local le plus simple et les petits jeux de données. Qdrant quand vous avez besoin de recherche filtrée de niveau production, de maîtrise de l'auto-hébergement, ou de scale au-delà d'un seul noeud. Un chemin courant consiste à prototyper sur Chroma puis à passer à Qdrant une fois les besoins de retrieval clairs.

ChromaDB vs pgvector : lequel choisir ?

pgvector si Postgres tourne déjà et que vous voulez du filtrage SQL, des jointures avec vos données et un seul datastore à opérer. Chroma si vous voulez un prototype Python sans base. Les deux plafonnent autour du million de vecteurs pour un trafic RAG typique, donc la décision porte sur votre stack existante, pas sur la capacité brute.

Pinecone vaut-il son coût ?

Oui si vous n'avez pas de capacité ops et que la tarification à l'usage colle à votre volume. Si vous pouvez auto-héberger, Qdrant ou pgvector coûteront en général moins cher et vous donneront plus de contrôle.

Faut-il une base vectorielle dédiée pour un petit RAG ?

Non. En dessous d'environ un million de vecteurs à des taux de requêtes RAG normaux, pgvector ou Chroma suffit. Passez à un moteur dédié quand vous avez une raison mesurée, pas en anticipation d'une raison.

En résumé : démarrez avec Chroma ou pgvector, gardez le vector store derrière une interface, et sortez Qdrant ou Pinecone quand une limite concrète, échelle, filtrage ou charge ops, force le changement. La base compte, mais moins que la qualité du retrieval que vous construisez par-dessus.