Qdrant ou pgvector pour votre RAG n8n : comment choisir sa base vectorielle

Au moment de monter un pipeline RAG dans n8n, une décision arrive très tôt et engage tout le reste : où stocker les embeddings ? Les deux réponses les plus courantes dans l'écosystème self-hosted sont pgvector, l'extension vectorielle de PostgreSQL, et Qdrant, un moteur de recherche vectorielle dédié. Les deux disposent d'un node vector store natif dans n8n, les deux se déploient en Docker à côté de votre instance, et les deux font très bien le travail — mais pas avec la même philosophie ni les mêmes conséquences opérationnelles. Ce guide compare les deux options sur les critères qui comptent vraiment pour un projet n8n, avec une recommandation honnête à la fin.

Deux philosophies de base vectorielle

pgvector : la recherche vectorielle dans la base que vous avez déjà

pgvector n'est pas une base de données : c'est une extension de PostgreSQL qui ajoute un type de colonne vector, des opérateurs de distance et des index approximatifs (HNSW, IVFFlat). Toute la proposition de valeur tient dans cette intégration :

• Une base de moins à opérer. Si votre stack repose déjà sur Postgres ou Supabase — ce qui est le cas de beaucoup d'instances n8n self-hosted —, la recherche vectorielle s'ajoute à l'existant sans nouveau service à déployer, superviser et sauvegarder.
• Les jointures SQL avec les données métier. Vos chunks vectorisés vivent dans une table Postgres comme les autres : vous pouvez les joindre à votre table clients, filtrer par tenant, croiser avec des droits d'accès, le tout dans une seule requête SQL.
• Les transactions. Insérer un document, ses chunks et ses embeddings dans une même transaction, avec rollback si une étape échoue, est naturel en SQL — c'est un vrai confort pour un pipeline d'ingestion fiable.
• L'outillage existant. Sauvegardes via pg_dump, réplication, monitoring, gestion des rôles : tout ce que vous savez faire avec Postgres s'applique tel quel à vos vecteurs.

La contrepartie : la recherche vectorielle reste une fonctionnalité parmi d'autres d'un moteur généraliste, avec les compromis d'index que détaille notre article HNSW ou IVFFlat pour pgvector.

Qdrant : un moteur dédié, conçu pour ne faire que ça

Qdrant est une base vectorielle spécialisée écrite en Rust, pensée dès le départ pour la recherche de similarité à grande échelle. Sa philosophie est inverse : plutôt qu'étendre un moteur généraliste, tout optimiser pour un seul usage.

• Une API propre et dédiée (REST et gRPC), organisée autour de collections de points, chacun portant un vecteur et un payload de métadonnées librement structuré.
• Un filtrage de payload avancé. C'est la signature de Qdrant : les filtres sur les métadonnées (conditions imbriquées, plages, correspondances géographiques, combinaisons must/should/must_not) sont intégrés au parcours de l'index lui-même, plutôt qu'appliqués après coup sur les résultats. Pour un RAG multi-tenant ou fortement filtré, c'est une différence d'architecture, pas de confort.
• La quantization intégrée. Qdrant peut compresser les vecteurs en mémoire (quantization scalaire, binaire ou par produit) pour réduire drastiquement l'empreinte RAM d'un gros corpus, avec un re-scoring sur les vecteurs originaux pour préserver la qualité.
• Un dimensionnement indépendant. La recherche vectorielle devient un service à part, qu'on peut scaler, redémarrer ou versionner sans toucher à la base métier.

La contrepartie est symétrique : un service de plus à déployer, superviser et sauvegarder, et des métadonnées séparées de vos données métier — toute jointure avec le reste du système passe par votre code ou vos workflows.

Ce que n8n supporte nativement

Bonne nouvelle : le choix n'engage presque pas la construction du workflow. n8n fournit des nodes vector store pour les deux options, utilisables de façon interchangeable dans les chaînes RAG :

• le node Qdrant Vector Store, qui se connecte à une instance Qdrant (self-hosted ou cloud) ;
• le node Supabase Vector Store et le node PGVector Vector Store, qui s'appuient sur une table pgvector — le premier via Supabase, le second sur n'importe quel PostgreSQL avec l'extension activée.

Dans les deux cas, le node fonctionne en mode insertion pour l'ingestion (recevoir des documents découpés, appeler le modèle d'embedding, écrire les vecteurs) et en mode retrieval comme outil d'un AI Agent ou d'une chaîne de question-réponse. Le reste du pipeline — le découpage des documents en chunks, le choix du modèle d'embeddings, l'éventuel reranking des résultats — est strictement identique quelle que soit la base. Migrer de l'une à l'autre revient à remplacer un node, recréer les credentials et réingérer le corpus.

Les critères qui font vraiment la différence

Le volume de vecteurs. C'est le critère le plus structurant. En dessous de quelques centaines de milliers de vecteurs, les deux options sont à l'aise. Entre quelques centaines de milliers et quelques millions, pgvector reste tout à fait viable avec un index HNSW correctement paramétré et une instance dimensionnée en conséquence. Au-delà de plusieurs millions de vecteurs, l'architecture dédiée de Qdrant — quantization, gestion mémoire spécialisée, sharding — commence à peser réellement dans la balance.

La complexité des filtres de métadonnées. Si vos recherches se limitent à « les documents de tel espace » ou « les chunks de tel type », les deux font l'affaire (pgvector via une clause WHERE, Qdrant via son payload). Si votre RAG doit combiner de nombreuses conditions imbriquées sur chaque requête — tenant, droits, période, tags, source —, le filtrage intégré à l'index de Qdrant est conçu exactement pour ça, là où un filtre SQL très sélectif combiné à un index approximatif demande plus de soin côté pgvector.

Votre stack existante. Une équipe déjà sur Postgres ou Supabase a tout intérêt à commencer par pgvector : les credentials existent, les connexions n8n vers Supabase sont documentées, et la montée en compétence est quasi nulle. Introduire Qdrant, c'est introduire un nouveau composant avec sa courbe d'apprentissage — justifiable, mais pas gratuit.

Le self-hosting. Égalité quasi parfaite : les deux se déploient en un conteneur Docker à côté de n8n, sur le même docker-compose.yml que celui de notre guide d'installation de n8n avec Docker. Qdrant demande un volume persistant pour ses collections ; pgvector vit dans le volume Postgres que vous avez déjà (ou dans un conteneur Postgres dédié si vous préférez isoler la base vectorielle de la base interne de n8n).

Les sauvegardes. C'est un point souvent négligé qui penche nettement côté pgvector : si vous suivez déjà une routine de sauvegarde PostgreSQL pour votre n8n self-hosted, vos vecteurs sont couverts par le même pg_dump, testés par la même procédure de restauration. Avec Qdrant, il faut mettre en place et tester un second mécanisme : ses snapshots de collections, à déclencher, stocker et restaurer séparément. Rien d'insurmontable, mais c'est une procédure de plus qui doit exister le jour où le disque lâche.

Tableau comparatif

Critère	pgvector	Qdrant
Nature	Extension PostgreSQL	Moteur vectoriel dédié (Rust)
Node n8n	Supabase Vector Store / PGVector Vector Store	Qdrant Vector Store
Services à opérer	Aucun de plus si Postgres existe déjà	Un conteneur supplémentaire
Jointures avec les données métier	Natives (SQL)	Via votre code / vos workflows
Transactions	Oui (ACID PostgreSQL)	Non (garanties par point/collection)
Filtrage de métadonnées	Clauses SQL WHERE	Filtrage de payload intégré à l'index, conditions riches
Quantization	Non intégrée	Scalaire, binaire, produit
Sauvegardes	pg_dump déjà en place	Snapshots Qdrant à mettre en place
Zone de confort	Jusqu'à quelques millions de vecteurs	Du modeste au très grand volume
Idéal pour	Équipes déjà sur Postgres/Supabase, RAG documentaire classique	Gros corpus, filtres complexes, recherche vectorielle comme service central

Méfiez-vous des benchmarks : testez sur vos propres données

Les comparatifs chiffrés qui circulent — souvent publiés par les éditeurs eux-mêmes — sont à prendre avec recul. La recherche académique sur le sujet est claire : l'étude de référence d'Aumüller, Bernhardsson et Faithfull, « ANN-Benchmarks: A Benchmarking Tool for Approximate Nearest Neighbor Algorithms », publiée dans Information Systems en 2020, montre que la performance des algorithmes de recherche approximative dépend fortement du jeu de données (dimension, distribution, métrique) et du compromis rappel/vitesse choisi : un algorithme qui domine sur un dataset à un niveau de rappel donné peut être dominé ailleurs. Autrement dit, aucun classement générique ne prédit ce que votre corpus, avec vos embeddings et vos filtres, donnera en production. Les travaux de Johnson, Douze et Jégou sur la recherche de similarité à très grande échelle (IEEE Transactions on Big Data, 2019) rappellent la même chose sous un autre angle : les gains spectaculaires viennent d'optimisations très dépendantes du matériel et du contexte. La bonne pratique pour un projet n8n : montez un petit jeu de questions de référence, mesurez le rappel et la latence sur vos données réelles avec chaque candidat, et décidez sur cette base plutôt que sur un graphique marketing.

Notre recommandation honnête

En dessous de quelques millions de vecteurs — c'est-à-dire pour la grande majorité des projets RAG construits avec n8n —, pgvector suffit largement. Un RAG documentaire d'entreprise, même nourri de milliers de PDF, dépasse rarement quelques centaines de milliers de chunks : à cette échelle, l'extension Postgres offre des latences confortables, des sauvegardes déjà en place et zéro service supplémentaire. C'est le choix par défaut que nous faisons dans notre guide RAG complet avec Supabase, et celui du Pack Assistant RAG (119 €), dont le workflow d'ingestion PDF vers Supabase pgvector livre la chaîne complète prête à importer. Le même raisonnement vaut pour une synchronisation Notion vers base vectorielle : le volume typique d'un espace de travail ne justifie pas un moteur dédié.

Qdrant se justifie quand l'un de ces signaux apparaît : un corpus qui se compte en millions de vecteurs et continue de croître ; des filtres de métadonnées riches et systématiques sur chaque requête ; une contrainte mémoire forte que la quantization résout élégamment ; ou une organisation où la recherche vectorielle devient un service partagé entre plusieurs applications, avec son propre cycle de vie. Dans ces cas, le coût opérationnel du service supplémentaire est largement remboursé.

Et si vous hésitez encore : commencez par pgvector. Le node vector store de n8n rend la migration vers Qdrant peu coûteuse le jour où les signaux ci-dessus apparaissent — il suffira de réingérer le corpus, ce que votre pipeline d'ingestion sait déjà faire.