Intermédiaire 10 minStack

pgvector : la recherche vectorielle dans PostgreSQL

pgvector est une extension de PostgreSQL qui ajoute le stockage et la recherche de vecteurs à une base que vous administrez déjà. Pour la plupart des projets de recherche documentaire locale, c'est un service de moins à faire tourner, une sauvegarde de moins à organiser, et des filtres SQL qui fonctionnent réellement — y compris sur les droits d'accès.

Par Mohamed Meguedmi·Màj 2026-09-21·Testé sur Windows, macOS, Linux

#L'argument : ne pas ajouter de service

Une installation documentaire locale fait déjà tourner un serveur de modèle, une étape d'encodage et un stockage de documents. Ajouter une base vectorielle dédiée, c'est un conteneur de plus, un port de plus, une sauvegarde de plus, et une chose de plus qui peut se désynchroniser de vos données relationnelles le jour où un document est supprimé.

Si PostgreSQL est déjà là — et dans une application métier, il l'est presque toujours — pgvector supprime toute cette catégorie de problèmes. Vos morceaux de texte vivent dans une table à côté des documents dont ils viennent, avec des clés étrangères qui les maintiennent cohérents, et une suppression se propage comme vous l'attendez.

#Comment ça marche en pratique

Le kit RAG Local

Tes documents, ton IA : un RAG local fiable sur tes PDF, notes et mails — sans rien envoyer dans le cloud.

  • Espace en ligne à vie
  • PDF + fichiers
  • Remboursé 30 j
Le kit RAG Local →ou tous les kits à vie — 49 € →

Vous stockez une colonne de vecteurs à côté de vos colonnes habituelles. Une requête trie les lignes par distance au vecteur de la question et renvoie les plus proches. Trois opérateurs de distance couvrent les cas courants, et celui que vous choisissez doit correspondre à la convention du modèle d'embedding : c'est la source la plus fréquente de résultats discrètement médiocres.

Les pièces du puzzle
ÉlémentCe que c'estÀ surveiller
Colonne vecteurUn tableau de flottants de dimension fixeLa dimension vient du modèle d'embedding et ne change pas sans tout réencoder
Opérateur de distanceCosinus, produit scalaire ou euclidienDoit correspondre au modèle
Index HNSWIndex en graphe, requêtes rapidesConstruction lente et gourmande en mémoire ; le défaut raisonnable aujourd'hui
Index IVFFlatIndex par partitions, peu coûteux à construireÀ créer une fois des données représentatives présentes
Aucun indexParcours exact de toutes les lignesParfaitement viable jusqu'à quelques dizaines de milliers de lignes

#Le filtrage, et les droits d'accès

Une question réelle porte rarement sur la totalité du corpus : on veut les passages de ce service, postérieurs à cette date, dans les documents que cet utilisateur a le droit de lire. Dans une base vectorielle dédiée, c'est un filtre de métadonnées avec sa syntaxe et ses cas limites. Dans PostgreSQL, c'est une clause WHERE à côté d'un tri par similarité, jointe à votre table d'utilisateurs si nécessaire.

!
Les droits ne se règlent pas dans le prompt
Quand plusieurs personnes interrogent un même index, le filtre sur les habilitations est ce qui empêche un modèle de citer à quelqu'un un document qu'il ne devrait pas voir. Aucune consigne de prompt ne remplace ce filtre, et l'exprimer en SQL contre votre modèle d'autorisation existant est bien plus sûr que de le réimplémenter.

#Là où ça s'arrête

La mémoire à grande échelle
Des millions de vecteurs en pleine précision, c'est volumineux ; les moteurs dédiés proposent des compressions agressives qui les gardent en mémoire. C'est l'écart le plus net.
Le temps de construction d'index
Un index en graphe sur une très grande table est long et gourmand.
La concurrence
De la recherche vectorielle lourde à côté de votre charge transactionnelle met les deux sur le même serveur.
La dimension des vecteurs
Les vecteurs indexés ont une borne supérieure de dimension. Les modèles courants passent ; les modèles à très grande dimension, non.
La recherche hybride
PostgreSQL sait faire de la recherche plein texte et vous pouvez la combiner à la distance vectorielle, mais l'ergonomie est à votre charge.

#pgvector ou une base dédiée

Choisir selon la situation
SituationChoix
PostgreSQL déjà en place, moins de quelques centaines de milliers de morceauxpgvector, confortablement
Les vecteurs doivent rester cohérents avec des données relationnellespgvector : les transactions le font gratuitement
Filtrage fin sur des habilitations existantespgvector
Des millions de vecteurs, beaucoup de requêtesUn moteur dédié
Prototype dans un carnet de notesN'importe lequel, ce choix est réversible

#FAQ

pgvector est-il assez rapide pour du RAG ?+
Pour un corpus local typique — de quelques dizaines à quelques centaines de milliers de morceaux — oui, avec un index en graphe, et souvent même sans index en bas de cette fourchette. La récupération est rarement l'étape lente d'une chaîne locale : c'est la génération.
pgvector ou Qdrant ?+
pgvector si PostgreSQL est déjà là et que vos données sont relationnelles : moins de services, cohérence transactionnelle, filtres SQL. Qdrant quand l'échelle, la quantification mémoire ou un service dédié comptent davantage.
Quel index choisir ?+
HNSW par défaut : meilleures performances en requête, au prix d'une construction plus lente et de plus de mémoire. IVFFlat est moins coûteux à construire mais doit être créé une fois des données représentatives présentes.
Puis-je filtrer par métadonnées ?+
Oui, en SQL ordinaire, jointures comprises. C'est l'une des meilleures raisons de le choisir, en particulier pour filtrer par droits d'accès.
Que se passe-t-il si je change de modèle d'embedding ?+
Tout doit être réencodé : la dimension et la géométrie des vecteurs appartiennent au modèle. C'est un traitement par lots sur GPU, pas une migration de schéma.
Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.