Pourquoi le choix de la base vectorielle est le vrai bottleneck de ton RAG en production
Quand tu construis un pipeline RAG, tu passes 80% de ton temps sur l’infra et 20% sur le LLM. C’est la réalité que peu de monde avoue. Le modèle, tu le changes en 5 lignes de code. Ta base de données vectorielle, c’est tout un chantier. Et pourtant, c’est elle qui décide si ton système tient la route en production ou si tu passes tes nuits à réindexer.
Pourquoi la base de données vectorielle devient-elle le facteur limitant ? Parce que la latence, le coût de ré-indexation et la dérive des embeddings sont des problèmes de production, pas de prototype. En dev, tout va bien avec 10 000 vecteurs. En prod, avec 10 millions, la donne change complètement.
Dans cet article, je compare pgvector, Qdrant et Weaviate sur 5 critères concrets : volumétrie, latence P99, coût d’hébergement mensuel, effort de ré-indexation et observabilité. Ce sont les seuls critères qui comptent vraiment quand tu passes en production. À la fin, tu sauras choisir sans te faire vendre du rêve.
Rappel : comment fonctionne une base de données vectorielle dans un pipeline RAG
Avant de comparer, un rapide rappel. Une base de données vectorielle stocke des vecteurs numériques produits par un modèle d’embedding. Chaque vecteur représente la signification sémantique d’un texte. La recherche de similarité (ANN, approximate nearest neighbor) trouve les vecteurs les plus proches d’une requête en utilisant des algorithmes comme HNSW ou IVF.
Le pipeline RAG classique se décompose en 5 étapes :
- Chunking : découpage des documents en segments de 200 a 800 tokens selon le modèle d’embedding
- Embedding : transformation de chaque chunk en vecteur via un modèle (OpenAI text-embedding-3-small, par exemple)
- Indexation : stockage des vecteurs dans la base avec création d’un index ANN
- Recherche de similarité : à chaque requête, recherche des k vecteurs les plus proches
- Reranking : réordonnancement des résultats pour améliorer la précision avant passage au LLM
La grande différence entre les solutions : pgvector est une extension de PostgreSQL, pas une base vectorielle pure. Qdrant et Weaviate sont des bases de données vectorielles dédiées, conçues des le départ pour ce workload. Cela change tout sur la gestion des index, le scaling et l’observabilité.
Les 5 critères de production qui font vraiment la différence
Dans la vraie vie, personne ne choisit une base de données vectorielle sur son nombre d’étoiles GitHub. Voici les 5 critères qui déterminent si ton système RAG survivra à la mise en production :
- Volumétrie : jusqu’à combien de vecteurs la solution tient sans dégradation ?
- Latence P99 : quel est le pire temps de réponse que tes utilisateurs vont subir ?
- Coût d’hébergement mensuel : combien tu vas vraiment payer pour faire tourner l’infra ?
- Effort de ré-indexation : combien de temps et de CPU tu perds à mettre à jour les index ?
- Observabilité : comment tu sais pourquoi ton agent répond n’importe quoi ?
Ces critères sont le fruit de mon expérience sur le terrain. J’ai eu l’occasion de tester ces solutions sur des volumes réels, et je partage les chiffres que j’aurais aimés trouver avant de faire mon choix.
Volumétrie : jusqu’où chaque solution monte sans craquer
La volumétrie est le premier critère qui élimine des solutions rapidement.
pgvector : c’est l’option la plus simple, mais elle a ses limites. Extension PostgreSQL, elle supporte jusqu’à 10 millions de vecteurs avant que la dégradation ne devienne visible. Au-delà, la latence augmente linéairement et il n’y a pas de scaling distribue natif. Pour un petit projet interne ou un MVP, c’est largement suffisant. Pour une application avec des millions d’utilisateurs, ça coince.
Qdrant : conçu pour le scaling horizontal. Le sharding est intégré nativement, ce qui permet de répartir les données sur plusieurs nœuds sans configuration complexe. Testé jusqu’à 100 millions de vecteurs par les équipes de Qdrant, il tient la charge sans broncher. Si tu passes de 1 à 50 millions de vecteurs, Qdrant scale sans que tu aies à revoir ton architecture.
Weaviate : même philosophie que Qdrant avec un scaling horizontal et un module de réplication intégré. Les benchmarks internes montrent une tenue à 50 millions de vecteurs et plus. Weaviate ajoute une couche de flexibilité avec la possibilité de combiner recherche vectorielle et filtrage par metadata.
Voici un tableau récapitulatif des volumes max par configuration :
| Solution | Volume max recommande | Scaling distribue | Sharding natif |
|---|---|---|---|
| pgvector | 10M vecteurs | Non | Non |
| Qdrant | 100M+ vecteurs | Oui | Oui |
| Weaviate | 50M+ vecteurs | Oui | Oui |
Latence P99 : le temps de réponse qui tue l’UX de ton agent
Un agent qui met plus de 500ms à répondre, c’est un agent qui tue l’expérience utilisateur. La latence P99 est la métrique clé : elle représente le pire cas, pas la moyenne. En production, c’est ce que tes utilisateurs vont ressentir.
pgvector : avec un index HNSW, la latence est comprise entre 5 et 20ms pour 1 million de vecteurs. Le problème, c’est la dégradation linéaire. Chaque million de vecteurs supplémentaire ajoute des millisecondes. À 10 millions, tu frêles les 200ms pour les requêtes les plus complexes. L’algorithme de distance et la dimension des embeddings (768 ou 1536) impactent directement les performances.
Qdrant : c’est le champion de la latence basse avec des temps compris entre 2 et 10ms pour 1 million de vecteurs. L’index HNSW est optimisé et le filtrage précoce (pre-filtering) permet de réduire l’espace de recherche avant même de calculer les distances. En pratique, pour 10 millions de vecteurs, Qdrant reste sous les 50ms P99, ce qui est excellent pour un agent conversationnel.
Weaviate : les latences oscillent entre 3 et 15ms pour 1 million de vecteurs. Weaviate combine flat search et HNSW selon le volume, avec un overhead lié à son module GraphQL. Pour des volumes intermédiaires (jusqu’à 10 millions), les performances sont comparables à Qdrant. Au-delà, l’écart se creuse légèrement en faveur de Qdrant sur la latence pure.
Coût d’hébergement : ce que personne ne te dit sur la facture mensuelle
Le coût est souvent le grand oublié des comparatifs. Pourtant, c’est lui qui décide de la viabilité de ton projet sur la durée. Voici ce que chaque solution coûte réellement.
pgvector : gratuit. L’extension PostgreSQL ne coûte rien. Le coût réel, c’est celui de ton instance PostgreSQL existante. Si tu as déjà une base en production, le coût marginal est quasi nul. Ajouter une colonne vectorielle à ta table existante ne change pas ta facture d’hébergement. Pour une start-up ou un projet solo, c’est l’option la plus économique.
Qdrant : open-source en self-hosted, ou cloud à partir de 50$/mois. Pour 10 millions de vecteurs, tu peux compter entre 50 et 200$/mois selon la RAM nécessaire et le stockage. Le modèle cloud propose des pods préconfigurés, ce qui simplifie le déploiement mais ajoute un coût d’infrastructure non négligeable.
Weaviate : open-source self-hosted, cloud embedded ou SaaS. Pour 10 millions de vecteurs, la facture mensuelle se situe entre 100 et 300$/mois. Weaviate est légèrement plus cher que Qdrant à volume équivalent, principalement à cause de l’overhead de son module de réplication et de ses fonctionnalités avancées de filtrage.
Quand tu ajoutes le coût de la RAM (les index HNSW sont gourmands en mémoire) et du stockage SSD, l’écart se creuse. Pour une entreprise qui manipule 50 millions de vecteurs, la différence entre pgvector et Qdrant peut représenter plusieurs milliers d’euros par mois.
Ré-indexation : le piège qui coûte des heures de calcul
La ré-indexation, c’est le truc dont personne ne parle dans les benchmarks. Pourtant, c’est ce qui va te coûter des heures de calcul CPU et de l’attention d’équipe.
pgvector : pas de ré-indexation automatique. Pour mettre à jour un index HNSW, tu dois dropper l’index et le recréer. Sur 10 millions de vecteurs, ça peut prendre plusieurs heures avec une consommation CPU intense. Pendant ce temps, les requêtes vectorielles sont dégradées voire indisponibles.
Qdrant : la ré-indexation est optimisée et segmentée. Tu peux activer ou désactiver les index sans downtime. Chaque segment peut être réindexé indépendamment, ce qui permet de maintenir la disponibilité pendant les opérations de maintenance. En pratique, la ré-indexation de 10 millions de vecteurs prend quelques dizaines de minutes.
Weaviate : la ré-indexation est automatique au niveau des shards. Le système maintient les index à chaud, ce qui évite les fenêtres de maintenance. Quand tu ajoutes des données, l’index se met à jour progressivement sans bloquer les lectures.
Le temps de ré-indexation pour 10 millions de vecteurs en HNSW :
- pgvector : 2 à 4 heures avec drop/recreate
- Qdrant : 20 à 40 minutes en segmentée
- Weaviate : 15 à 30 minutes en automatique
Observabilité : savoir pourquoi ton agent répond n’importe quoi
Quand ton agent RAG se met à halluciner ou à répondre à côté, tu dois pouvoir debugger rapidement. L’observabilité est la différence entre une résolution en 10 minutes et une enquête de 3 jours.
pgvector : pas d’outillage natif pour les requêtes vectorielles. Tu te retrouves avec les logs PostgreSQL standard, qui ne te disent rien sur la qualité des résultats de similarité. Impossible de savoir si le problème vient de l’index, de la dimension des embeddings ou du modèle lui-même.
Qdrant : expose des métriques Prometheus nativement. Health checks, tracing des requêtes par payload, temps de réponse par collection : tout est remonté. Tu peux mettre en place des alertes sur la latence P99 ou le nombre de requêtes échouées. En production, c’est indispensable pour détecter une dérive des performances avant que les utilisateurs ne s’en plaignent.
Weaviate : module de monitoring intégré avec des métriques sur le contexte de requête. L’observabilité du pipeline est plus poussée que chez Qdrant sur certains aspects, notamment le tracing des étapes de la requête (recherche, filtrage, reranking). En contrepartie, la configuration du monitoring est un peu plus complexe.
Tableau comparatif récapitulatif : pgvector, Qdrant, Weaviate face a face
| Critere | pgvector | Qdrant | Weaviate |
|---|---|---|---|
| Type | Extension PostgreSQL | Base vectorielle dédiée | Base vectorielle dédiée |
| Volumétrie max | 10M vecteurs | 100M+ vecteurs | 50M+ vecteurs |
| Latence P99 (1M vecteurs) | 5-20ms | 2-10ms | 3-15ms |
| Cout mensuel (10M vecteurs) | Gratuit (coût PG) | 50-200$ | 100-300$ |
| Ré-indexation | Manuelle (drop/recreate) | Segmentée sans downtime | Automatique par shard |
| Observabilité | Logs PostgreSQL | Métriques Prometheus | Monitoring intégré |
| Scaling distribue | Non | Oui (sharding natif) | Oui (réplication) |
| Intégration LangChain/LlamaIndex | Complète | Complète | Complète |
| Maturité documentation | Excellente | Très bonne | Très bonne |
Ce tableau résume les différences clés. L’intégration avec LangChain et LlamaIndex est bonne pour les 3 solutions, ce qui n’est pas un facteur discriminant. La vraie différence se joue sur la volumétrie, la latence et le cout.
Quand choisir pgvector, Qdrant ou Weaviate : l’arbre de décision
Voici les scénarios typiques pour t’aider à faire ton choix.
Si tu as déjà PostgreSQL et moins de 1 million de vecteurs : pgvector. C’est le choix le plus simple, le moins cher et le plus rapide à mettre en œuvre. Tu ajoutes une extension à ta base existante, tu crées un index HNSW, et tu es opérationnel en quelques heures. C’est parfait pour un MVP, un chatbot interne avec peu de documents, ou un projet solo.
Si tu passes à l’échelle avec des besoins de latence faible : Qdrant. Qdrant est le meilleur rapport performance/prix pour les applications de production avec des volumes importants. Le scaling horizontal natif et la ré-indexation sans downtime en font un choix solide pour les équipes techniques. Si tu construis un agent destiné à des centaines d’utilisateurs avec des milliers de documents, Qdrant est le choix le plus sûr.
Si tu as besoin de capacités multimodales et de filtrage avancé : Weaviate. Weaviate excelle quand tu dois combiner recherche vectorielle, filtrage par metadata et capacités multimodales (texte, image, audio). Son module GraphQL est puissant mais ajoute de la complexité. Choisis-le si tes besoins de requêtage sont avancés et que tu as les ressources pour le configurer.
Si tu veux du SaaS sans t’occuper de l’infra : Qdrant Cloud ou Weaviate Cloud. Les deux proposent des offres cloud managed. Qdrant Cloud est généralement moins cher à volume équivalent. Weaviate Cloud offre plus de fonctionnalités intégrées. Dans les deux cas, tu ne gères pas l’infrastructure, mais tu perds en contrôle sur la configuration fine des index.
Cas particulier : Pinecone. Pinecone mérite une mention rapide même s’il est hors scope de ce comparatif open-source. C’est une solution SaaS pure, zero-ops, avec des performances excellentes, mais un coût élevé et pas de possibilité de self-hosting. Si tu veux démarrer vite sans équipe infrastructure et que le budget n’est pas un problème, Pinecone est une option valable.
Les pièges qu’on a rencontrés en production (et comment les éviter)
J’ai fait les erreurs pour toi. Voici les 4 pièges les plus fréquents qu’on rencontre avec les bases de données vectorielles en production.
Piège 1 : la dimension des embeddings. Plus la dimension est haute, plus le calcul de similarité est lent. Avec des embeddings OpenAI à 1536 dimensions, les performances sont 2 à 3 fois moins bonnes qu’avec des embeddings à 768 dimensions (comme ceux de BGE ou de certaines alternatives open-source). Le compromis : tester différentes dimensions et mesurer l’impact sur le recall avant de se fixer. Ne pars pas sur du 1536 par défaut, vérifie si ton cas d’usage le nécessite vraiment.
Piège 2 : le chunking qui ruine le recall. La taille des chunks, l’overlap et la stratégie de découpage ont un impact direct sur la qualité de la recherche. Un chunk trop large noie l’information pertinente dans du bruit. Un chunk trop court perd le contexte. La fenêtre glissante et le découpage sémantique sont les stratégies les plus efficaces, mais elles coûtent plus cher en calcul. Teste différentes configurations sur ton jeu de données avant de les figer.
Piège 3 : le coût caché de la ré-indexation quotidienne. Si tu réindexes tous les jours sans optimisation, tu consommes des heures de CPU et tu dégrades les performances pendant les fenêtres de maintenance. Avec pgvector, le drop/recreate quotidien peut rendre ton service indisponible 30 minutes par jour. La solution : passer sur Qdrant ou Weaviate, ou adopter une stratégie d’indexation incrémentale.
Piège 4 : l’observabilité oubliée. Pas de métriques, pas de debug possible. Quand ton agent se met à répondre n’importe quoi, tu passes des heures à chercher la cause. Configure les métriques Prometheus (Qdrant) ou le monitoring intégré (Weaviate) dès le premier jour. Ajoute des logs sur les temps de requête, le nombre de résultats retournés et les scores de similarité. C’est le seul moyen de détecter une dérive avant qu’elle n’impacte les utilisateurs.
Mon retour d’expérience personnel : sur mon chatbot interne, j’ai commencé avec pgvector parce que c’était simple et gratuit. Quand je suis passé à 8 000 chunks de documentation technique, la latence a commencé à devenir problématique et la ré-indexation prenait trop de temps. J’ai migré vers Qdrant et le gain a été immédiat : latence divisée par 3, ré-indexation en 15 minutes au lieu de 2 heures.
FAQ : les questions qu’on se pose avant de choisir sa base vectorielle
Est-ce que je peux utiliser pgvector avec mon PostgreSQL existant ? Oui, c’est même l’intérêt principal de pgvector. Tu ajoutes l’extension à ta base existante, tu crées une colonne de type vector, et tu es prêt. Pas de nouvelle infrastructure, pas de coût supplémentaire. Parfait pour commencer rapidement.
Qdrant ou Weaviate pour un chatbot interne ? Les deux fonctionnent très bien. Qdrant est plus léger à déployer et moins cher. Weaviate offre plus de fonctionnalités si tu as besoin de filtrage avancé ou de capacités multimodales. Pour un chatbot interne standard, Qdrant est le meilleur rapport simplicité/performance.
Quel est le coût réel d’un RAG en production ? Tout dépend de ton volume de données et de tes contraintes de latence. Pour 10 millions de vecteurs avec des embeddings à 768 dimensions, compte 50 a 200$/mois pour l’infrastructure vectorielle (Qdrant Cloud), plus le coût de ton modèle d’embedding (quelques dizaines de dollars par mois selon l’API utilisée) et celui du LLM. Le coût total peut varier de 200 à 2000$/mois selon l’échelle.
Faut-il un modèle d’embedding spécifique avec chaque base vectorielle ? Non. Toutes les bases vectorielles supportent n’importe quel modèle d’embedding du moment que les vecteurs sont au bon format. Le choix du modèle (OpenAI, BGE, Sentence Transformers, etc.) est indépendant du choix de la base. Ce qui compte, c’est que la dimension des embeddings soit compatible avec les performances attendues.
Peut-on changer de base vectorielle sans réindexer toutes les données ? C’est techniquement complexe. Chaque base a son propre format d’index et de stockage. Il n’existe pas d’outil de migration automatique entre pgvector, Qdrant et Weaviate. Si tu changes de solution, tu dois exporter tes embeddings, les reformater et les réindexer dans la nouvelle base. Anticipe ce coût si tu penses changer plus tard.
Conclusion : par quoi commencer concrètement
Le choix de ta base de données vectorielle dépend de ton volume, de ton budget et de tes contraintes de production. Voici les 3 scénarios types avec ma recommandation :
- Prototype ou petit projet (< 1M vecteurs) : commence par pgvector. Simple, gratuit, suffisant pour valider ton concept.
- Application en production (1M à 50M vecteurs) : choisis Qdrant. Le meilleur rapport performance/prix pour les équipes techniques.
- Application enterprise avec besoins avancés (> 50M vecteurs) : Qdrant ou Weaviate selon tes besoins de filtrage et de multimodalité.
Dans mon cas, le choix s’est porté sur Qdrant pour le chatbot interne que je documente sur ce blog. La différence de performance avec pgvector a été flagrante dès les premiers tests avec des volumes réels.
Si tu veux suivre l’aventure, abonne-toi !
