Postgres (pgvector) vs base vectorielle dédiée : quand votre base actuelle suffit
Pour la majorité des projets RAG de taille modeste à moyenne, PostgreSQL avec l'extension pgvector et la recherche full-text native suffit largement : pas besoin d'ajouter une base vectorielle dédiée à votre stack. Ce guide détaille ce que Postgres sait déjà très bien faire, où pgvector montre ses limites, et les signaux concrets qui indiquent qu'il est temps de migrer vers une base spécialisée.
Postgres full-text search : une recherche par mots-clés déjà très capable
Avant même de parler de vecteurs, Postgres embarque depuis longtemps un moteur de recherche textuelle solide. Les types tsvector et tsquery transforment un texte en une structure indexable, avec stemming (racinisation) intégré pour plusieurs langues dont le français : « recherché » et « recherche » matchent la même racine. Un index GIN sur la colonne tsvector rend les requêtes rapides même sur des millions de lignes, et la fonction ts_rank calcule un score de pertinence basé sur la fréquence et la position des termes.
La vraie force de cette approche, c'est qu'elle reste du SQL pur : vous combinez une recherche full-text avec des filtres WHERE classiques (date, statut, client, catégorie) dans une seule requête transactionnelle. Pas de pipeline de synchronisation entre deux systèmes, pas de risque d'incohérence entre les données « source de vérité » et l'index de recherche : tout vit dans la même base, avec les mêmes garanties ACID.
Pgvector : la recherche vectorielle sans quitter votre base relationnelle
L'extension pgvector ajoute un type de colonne vector qui stocke un embedding (voir les embeddings expliqués simplement si le concept n'est pas clair) directement à côté de vos autres colonnes. Vous pouvez alors exécuter des requêtes de similarité avec les opérateurs dédiés (distance cosinus, distance euclidienne, produit scalaire négatif) et les combiner à des index approximatifs comme IVFFlat ou HNSW pour accélérer la recherche sur de gros volumes. Pour une vue d'ensemble du fonctionnement d'une base vectorielle, notre article sur qu'est-ce qu'une base de données vectorielle détaille les mécanismes sous-jacents.
Les avantages concrets de rester dans Postgres
- Une seule source de vérité : les documents, leurs métadonnées et leurs embeddings vivent dans les mêmes tables, avec des jointures SQL classiques.
- Des transactions ACID : un insert de document et son embedding réussissent ou échouent ensemble, pas de désynchronisation possible.
- Aucune pipeline de réplication supplémentaire à maintenir entre deux systèmes de stockage.
- Les outils d'exploitation existants (sauvegardes, monitoring, réplication, alerting) fonctionnent déjà sur votre instance Postgres.
- Une équipe qui connaît déjà l'administration Postgres n'a pas de nouvelle compétence à acquérir en urgence.
Recherche hybride : combiner mots-clés et vecteurs dans la même requête
La recherche purement sémantique rate parfois les correspondances exactes (un numéro de référence, un code produit, un acronyme précis), tandis que la recherche par mots-clés rate les reformulations. L'approche la plus robuste consiste à combiner les deux, comme expliqué dans notre article sur la recherche hybride BM25 et vecteurs. Dans Postgres, cela revient concrètement à exécuter les deux requêtes (ts_rank côté full-text, distance cosinus côté pgvector), puis à fusionner les résultats avec une méthode comme le reciprocal rank fusion, ou à pondérer les deux scores normalisés dans une requête SQL unique avant de reclasser les meilleurs candidats.
Cette fusion reste gérable tant que les volumes restent raisonnables et que les deux index (GIN pour le texte, HNSW ou IVFFlat pour les vecteurs) tiennent correctement en mémoire. C'est d'ailleurs l'approche retenue par plusieurs briques du stack RAG open source en 2026 qui s'appuient sur Postgres comme moteur unique plutôt que d'empiler des services.
Les limites de pgvector à grande échelle
Pgvector n'est pas magique : les index HNSW consomment de la mémoire proportionnellement au nombre de vecteurs et à leur dimension, et leur construction peut devenir longue sur de très gros volumes. Chaque insertion ou mise à jour déclenche un travail d'indexation supplémentaire, ce qui augmente l'amplification d'écriture et sollicite davantage l'autovacuum si le volume de modifications est élevé. Le réglage fin du compromis rappel/vitesse (paramètres ef_search, m, lists selon le type d'index) demande une vraie expertise d'exploitation, que beaucoup d'équipes n'ont pas en interne.
Autre limite : pgvector n'offre pas nativement de sharding horizontal ni d'isolation multi-tenant poussée. Si vous devez répartir des milliards de vecteurs sur plusieurs machines avec une isolation stricte par client, vous sortez du cas d'usage pour lequel pgvector a été pensé.
Postgres + pgvector vs base vectorielle dédiée
| Critère | Postgres + pgvector | Base vectorielle dédiée |
|---|---|---|
| Volume de vecteurs | Confortable jusqu'à quelques millions | Conçue pour des centaines de millions à des milliards |
| Latence à grande échelle | Correcte, dépend du réglage des index | Optimisée nativement, souvent plus stable sous charge |
| Mises à jour fréquentes | Bonne tant que l'autovacuum suit | Pensée pour l'ingestion continue à haut débit |
| Filtrage métadonnées complexe | Possible via SQL, performant si bien indexé | Souvent natif et optimisé dans le moteur |
| Scalabilité horizontale | Limitée sans solution externe (Citus, réplicas) | Sharding et réplication intégrés |
| Coût d'exploitation | Faible si Postgres déjà en place | Coût d'une infrastructure ou d'un service en plus |
| Compétences requises | DBA Postgres classique | Expertise spécifique au moteur choisi |
Quand une base vectorielle dédiée devient nécessaire
Il n'y a pas de seuil universel, mais certains signaux reviennent systématiquement dans les retours d'expérience d'équipes qui migrent. Pour comparer les options spécialisées et leurs coûts réels, nos articles sur les alternatives à Pinecone pour les petites équipes et sur le prix d'une base de données vectorielle détaillent les ordres de grandeur à anticiper.
- Vous dépassez plusieurs dizaines de millions d'embeddings et les temps de construction ou de maintenance d'index deviennent un problème opérationnel récurrent.
- Vous devez isoler strictement les données de centaines de clients (multi-tenant) avec des garanties de performance par tenant.
- Votre produit exige une latence P99 très basse sous forte charge concurrente, au-delà de ce que votre instance Postgres actuelle peut absorber sans retravailler toute l'infrastructure.
- Votre équipe grandit vers un rôle dédié « infrastructure IA » qui justifie d'investir dans un moteur spécialisé et son exploitation.
- Vous avez besoin de fonctionnalités avancées propres à certains moteurs : filtrage par métadonnées imbriquées très complexe, quantification agressive des vecteurs, ou réplication multi-région native.
Et si vous n'avez pas envie de choisir une infrastructure du tout ?
Entre « rester sur Postgres » et « déployer une base vectorielle dédiée », il existe une troisième option : ne pas gérer d'infrastructure de recherche du tout. C'est le principe du RAG as a service : vous déposez vos documents, le découpage, l'indexation et la recherche hybride (texte et sémantique) sont gérés pour vous. Sur Kopik, créer une base de connaissances se fait en quelques minutes via l'interface de création : vous importez vos PDF, Word ou Markdown, et la plateforme s'occupe de l'extraction, du chunking et de l'indexation hybride sans que vous ayez à régler des paramètres HNSW ou à surveiller un autovacuum. Les questions peuvent être posées depuis le site, via une API REST documentée, ou via un serveur MCP utilisable depuis des clients comme Claude ou Cursor. C'est une option pertinente quand votre priorité est de livrer vite un assistant documentaire fiable, plutôt que d'opérer vous-même une couche de recherche.
Le bon réflexe avant de migrer
Avant d'ajouter une base vectorielle dédiée à votre stack, mesurez d'abord où se situe réellement le goulot d'étranglement : temps de construction d'index, latence de requête, ou mémoire disponible. Un problème de réglage pgvector mal diagnostiqué se résout parfois par un meilleur index ou un cache applicatif, pas forcément par un changement de moteur.
Comment trancher pour votre projet : la checklist
Avant de décider, posez-vous ces questions concrètes plutôt que de suivre une mode technologique :
- Combien de documents et d'embeddings avez-vous aujourd'hui, et quelle est la projection réaliste à 12 et 24 mois ?
- Votre équipe a-t-elle déjà une expertise d'administration Postgres, ou faudrait-il l'acquérir de toute façon pour pgvector ?
- Avez-vous un besoin réel de filtrage métadonnées très complexe à l'échelle de millions de documents, ou des filtres SQL simples suffisent ?
- Votre budget favorise-t-il une base déjà payée (Postgres existant) ou justifie-t-il un service managé supplémentaire ?
- Préférez-vous investir du temps d'ingénierie dans l'exploitation d'un moteur de recherche, ou le déléguer pour vous concentrer sur le produit ?
Pour aller plus loin sur les mécanismes de récupération et leur évaluation une fois votre choix fait, consultez notre guide sur comment fonctionne le RAG étape par étape ou notre méthode pour évaluer un système RAG.
Tester sans construire d'infrastructure
Avant d'investir dans le réglage de pgvector ou l'achat d'une base vectorielle dédiée, essayez une alternative sans serveur à gérer : créez une base de connaissances sur Kopik et comparez la qualité des réponses obtenues.
FAQ
Questions fréquentes
Pgvector peut-il remplacer complètement une base vectorielle dédiée ?
Pour la majorité des projets, oui, surtout si votre volume reste sous quelques millions de vecteurs et que vous avez déjà une instance Postgres bien administrée. Les besoins de sharding massif, d'isolation multi-tenant poussée ou de latence extrême à très grande échelle sont les cas où une base dédiée garde un avantage net.
Quelle est la différence entre les index IVFFlat et HNSW dans pgvector ?
IVFFlat découpe l'espace vectoriel en clusters et ne cherche que dans les clusters les plus proches, ce qui est rapide à construire mais moins précis. HNSW construit un graphe de voisinage hiérarchique, plus coûteux en mémoire et en temps de construction, mais généralement plus rapide et plus précis en recherche, surtout quand les données sont mises à jour fréquemment.
Faut-il encore du full-text search si on a déjà des embeddings ?
Oui dans la plupart des cas. La recherche sémantique rate les correspondances exactes comme les codes produits, références ou acronymes précis, alors que le full-text les capture directement. Combiner les deux via une recherche hybride donne généralement de meilleurs résultats que chaque méthode seule.
À partir de combien de vecteurs pgvector commence-t-il à ralentir ?
Il n'y a pas de seuil universel : cela dépend du matériel, de la dimension des embeddings et du réglage de l'index. En pratique, au-delà de quelques dizaines de millions de vecteurs avec des mises à jour fréquentes et un filtrage complexe, les temps de construction d'index et la latence deviennent des points de vigilance sérieux.
Pgvector fonctionne-t-il avec des Postgres managés comme Supabase ou Neon ?
Oui, les principaux fournisseurs de Postgres managé proposent l'extension pgvector prête à l'emploi, ce qui simplifie grandement l'adoption : vous l'activez avec une simple commande CREATE EXTENSION sans gérer vous-même la compilation ou l'installation.
Quelle est l'alternative si je ne veux gérer ni Postgres ni une base vectorielle dédiée ?
Une plateforme de RAG as a service comme Kopik permet d'importer des documents et d'interroger une base de connaissances avec recherche hybride déjà configurée, sans administrer vous-même l'infrastructure de recherche, via le site, une API ou un serveur MCP.
Recevez la newsletter Kopik
Nouvelles bases de connaissances, guides sur le RAG et nouveautés du produit. Un mail toutes les une à deux semaines, désinscription en un clic.
En vous abonnant, vous acceptez de recevoir notre newsletter. Votre adresse n'est jamais partagée.