pgvector ou Qdrant : quelle base vectorielle pour votre RAG ?

Un projet de RAG ou de recherche sémantique stocke des embeddings, des vecteurs, et cherche les plus proches d'une requête. Deux options reviennent : pgvector, une extension de PostgreSQL, et Qdrant, une base vectorielle dédiée. Le bon choix dépend du volume et de votre stack.

pgvector : une seule base pour tout

pgvector ajoute le type vecteur et la recherche de similarité directement dans PostgreSQL. Vos embeddings vivent à côté de vos données métier, dans la même base, souvent Supabase.

• Une seule base à administrer, sauvegarder, sécuriser.
• Vos vecteurs et vos données relationnelles se croisent dans une même requête SQL.
• Hébergeable en Europe ou en self-hosted, comme le reste de votre PostgreSQL.

Pour la grande majorité des projets, de quelques centaines de milliers à quelques millions de vecteurs, pgvector suffit largement. C'est notre choix par défaut, détaillé sur notre page Agence Supabase.

Une limite technique mérite d’être vérifiée avant de trancher, car elle surprend souvent au moment de créer l’index. pgvector propose deux types d’index approximatifs, HNSW, plus rapide en interrogation mais plus lent et plus gourmand à construire, et IVFFlat, l’inverse. Or le type vector n’est indexable que jusqu’à 2 000 dimensions; halfvec, en demi-précision, monte à 4 000. Un embedding à 3 072 dimensions, taille courante chez les fournisseurs actuels, ne s’indexe donc pas directement : il faut passer en demi-précision, réduire la dimension à la génération, ou indexer des sous-vecteurs. Ce point se règle en une ligne de SQL quand on le connaît, et bloque une après-midi quand on le découvre.

Qdrant : la base dédiée pour le très gros volume

Qdrant est conçu uniquement pour les vecteurs. À très grande échelle (dizaines de millions de vecteurs, latence critique, filtrage complexe sur les métadonnées), une base dédiée tient mieux la charge et offre des fonctionnalités avancées de filtrage et de quantification. Le prix à payer : une brique de plus à exploiter, à côté de votre PostgreSQL.

Ce que Qdrant apporte à cette échelle tient surtout à la mémoire. La quantification, scalaire, binaire ou par produit, réduit fortement l’empreinte des vecteurs en RAM, au prix d’une perte de précision qu’on rattrape par un réordonnancement des meilleurs candidats sur les vecteurs d’origine. C’est ce qui rend tenable un index de dizaines de millions de vecteurs sur une machine raisonnable. À quelques centaines de milliers de vecteurs, ce mécanisme ne sert à rien : c’est précisément la frontière entre les deux approches.

Comment choisir

• pgvector si votre volume est raisonnable et que vous voulez une stack simple, ce qui couvre la plupart des cas métier.
• Qdrant (ou équivalent dédié) si vous visez un très gros volume, une latence serrée ou du filtrage avancé.

Dans les deux cas, le vrai sujet reste l'architecture du RAG autour : découpage, qualité des embeddings, filtrage des résultats. On en parle dans notre article sur le RAG en entreprise, et c'est au cœur de nos assistants IA connectés à vos données.

Ce point mérite d’être appuyé, parce qu’il décide de la qualité perçue bien plus que le moteur choisi. Un RAG se juge sur deux mesures, pas sur une impression : le rappel, la bonne réponse figure-t-elle dans les passages retrouvés?, et la fidélité, c’est-à-dire la part d’affirmations non appuyées par ces passages. Le classement public de Vectara mesure précisément cette seconde dimension sur une tâche de résumé fidèle ; les meilleurs modèles restent à quelques pour cent d’hallucination, ce qui n’est pas zéro. Cinquante questions annotées à la main sur vos propres documents en disent plus qu’un comparatif de bases vectorielles.

Un projet de recherche sémantique à dimensionner ? On vous aide à choisir la bonne base.