pgvector

pgvector est une extension open source pour PostgreSQL qui ajoute la recherche de similarité vectorielle à toute base de données Postgres existante. Créée par Andrew Kane en 2021 et publiée sous la licence PostgreSQL (une licence open source permissive similaire à MIT), elle vous permet de stocker des embeddings à haute dimension en tant que type de colonne natif et d'exécuter des requêtes approximatives des plus proches voisins à l'aide d'opérateurs SQL standards. L'extension est disponible sur github.com/pgvector/pgvector, compte plus de 13 000 étoiles GitHub en avril 2026 et est prise en charge nativement par Amazon RDS, Amazon Aurora, Google Cloud SQL, Azure Database for PostgreSQL, Supabase et Neon, entre autres. Il n'y a pas de fournisseur, pas d'abonnement et pas de frais par requête : le coût correspond uniquement à ce que vous payez pour faire tourner Postgres.

L'extension ajoute trois opérateurs de distance : <-> pour la distance L2 (euclidienne), <#> pour le produit scalaire, et <=> pour la distance cosinus. Elle prend en charge deux types d'index : IVFFlat (recherche approximative basée sur des partitions nécessitant une étape d'entraînement) et HNSW (Hierarchical Navigable Small World, ajouté dans la v0.5.0 en octobre 2023, qui se construit de manière incrémentielle et offre un meilleur rappel sans phase d'entraînement). Vous pouvez stocker des vecteurs allant jusqu'à plusieurs milliers de dimensions selon la version, ce qui la rend compatible avec les modèles d'embedding d'OpenAI, Cohere, Google et d'autres. Les requêtes s'exécutent dans Postgres, vous pouvez donc utiliser des JOIN pour associer les résultats vectoriels à vos tables relationnelles habituelles, appliquer des politiques de sécurité au niveau des lignes et utiliser votre pool de connexions et votre ORM existants sans aucune nouvelle infrastructure.

Ce que fait réellement pgvector en avril 2026

La version stable actuelle de pgvector (v0.8.x) est fournie comme une extension Postgres standard : une seule commande CREATE EXTENSION vector; l'active dans n'importe quelle base de données compatible. Vous définissez une colonne vectorielle avec un nombre de dimensions déclaré (embedding vector(1536) pour les embeddings OpenAI ada-002, par exemple), insérez les embeddings aux côtés de vos données habituelles avec un INSERT standard, et interrogez à l'aide d'opérateurs de distance dans une clause WHERE ou ORDER BY. L'index HNSW, ajouté en octobre 2023, est désormais le type d'index recommandé pour les charges de travail en production dépassant environ 100 000 vecteurs. Il prend en charge les insertions simultanées sans étape de reconstruction et offre systématiquement un rappel supérieur à 95 % à des vitesses de requête raisonnables. IVFFlat reste disponible pour les charges de travail où le coût de la phase d'entraînement est acceptable et la mémoire limitée. Les deux types d'index prennent en charge la création d'index en parallèle dans les versions récentes de Postgres. L'extension est activement maintenue, avec des commits réguliers et les principaux fournisseurs de cloud qui intègrent les nouvelles versions dans les semaines suivant leur publication.

Où se situe pgvector par rapport à Pinecone et Qdrant

Le marché des bases de données vectorielles en avril 2026 se divise grosso modo en trois camps : les services gérés spécialisés (Pinecone), les bases de données dédiées open source (Qdrant, Weaviate, Chroma) et les extensions Postgres (pgvector). Les compromis sont concrets et architecturaux.

pgvector vs. Pinecone : Pinecone est un service fermé et entièrement géré, conçu de A à Z pour la recherche approximative des plus proches voisins à grande échelle. Son architecture distribuée gère des milliards de vecteurs de manière plus fluide que pgvector ne peut le faire au sein d'une seule instance Postgres. Il propose des mises à jour d'index en temps réel, un filtrage des métadonnées intégré directement dans l'index (et non via une clause SQL WHERE post-requête), et une interface REST/SDK sans SQL. La version serverless de Pinecone est théoriquement gratuite au départ, mais les niveaux payants commencent autour de $70 par mois une fois que la taille de l'index augmente. Le compromis principal réside dans le plafond de performances et la dépendance vis-à-vis du fournisseur, face à la simplicité de rester dans Postgres. Si vous avez déjà une application Postgres, Pinecone nécessite un nouveau service, un nouveau client API, une nouvelle relation de facturation et un code d'application qui interroge deux magasins de données différents et corrèle les résultats. pgvector garde tout au même endroit.

pgvector vs. Qdrant : Qdrant est une base de données vectorielle open source et auto-hébergeable écrite en Rust, également disponible en tant que service cloud géré. Elle utilise HNSW comme index principal (le même algorithme que pgvector a adopté dans la v0.5.0) mais implémenté spécifiquement pour les charges de travail vectorielles, ce qui se traduit par un QPS brut plus élevé à rappel équivalent, en particulier sous une forte charge simultanée. Qdrant traite le filtrage de la charge utile (payload) comme une primitive d'indexation de premier ordre : les filtres de métadonnées sont intégrés dans le parcours HNSW, et non appliqués comme un filtre post-requête. Les benchmarks montrent systématiquement que Qdrant surpasse pgvector en termes de débit à forte concurrence. Le coût est opérationnel : Qdrant est un service stateful distinct avec son propre déploiement, format de stockage, API et monitoring. Vous ne pouvez pas utiliser de JOIN pour associer les résultats de Qdrant à votre table d'utilisateurs Postgres en une seule requête ; vous récupérez les données depuis Qdrant, puis vous les correlez dans le code de l'application ou avec un deuxième aller-retour vers la base de données. Pour les équipes disposant de la bande passante DevOps pour gérer un autre service et des charges de travail vectorielles qui dépasseront les 20 à 50 millions de lignes, Qdrant est le choix technique le plus solide. Pour tous les autres, l'argument « c'est juste votre Postgres » de pgvector est difficile à ignorer.

"Nous avons migré de Pinecone vers pgvector le trimestre dernier. Notre latence de requête p99 est plus élevée, mais nous avons éliminé une dépendance d'infrastructure entière et notre facture mensuelle a baissé d'environ $400. Pour notre échelle, moins de 5 millions de vecteurs, c'était la bonne décision." -- throwaway_ml_eng, Hacker News, novembre 2023

À quoi ressemble la réalité du flux de travail au quotidien

Le flux de travail pgvector le plus courant est un pipeline RAG (génération augmentée par la recherche) : découper des documents, générer des embeddings via un appel API à OpenAI ou Cohere, stocker l'embedding et le texte source dans une table Postgres, puis au moment de la requête, générer un embedding pour la question de l'utilisateur et récupérer les top-K fragments les plus proches pour les injecter dans un prompt LLM. Avec pgvector, il s'agit d'une seule requête SQL. L'embedding réside dans la même base de données que vos utilisateurs, documents, permissions et journaux d'audit. La sécurité au niveau des lignes s'applique automatiquement. Votre monitoring Postgres existant (pg_stat_statements, journaux de requêtes lentes, Datadog, etc.) couvre les requêtes vectorielles. Les migrations ne sont que des instructions ALTER TABLE.

La version v0.5.0 d'octobre 2023, qui a ajouté l'indexation HNSW, a été le moment où la communauté a largement jugé pgvector prêt pour la production. Avant cette version, IVFFlat était la seule option d'index approximatif. IVFFlat nécessite une étape d'entraînement explicite (SET ivfflat.probes) après le chargement de vos données, dégrade le rappel avec un faible nombre de sondes sur de grands ensembles de données, et ne peut pas se mettre à jour de manière incrémentielle sans un réentraînement périodique. De multiples pannes en production et articles de blog de 2022-2023 ont été attribués à la dégradation du rappel d'IVFFlat à mesure que les collections augmentaient. HNSW a éliminé l'exigence d'entraînement et a relevé le niveau du rappel pratique. Le fil de discussion GitHub annonçant la v0.5.0 a accumulé des centaines de commentaires en quelques jours, des équipes signalant un soulagement immédiat face à des problèmes de production de longue date.

"La prise en charge de l'index HNSW dans la 0.5.0 a été ce qui a rendu pgvector réellement utilisable pour nous. Avant cela, nous faisions des analyses de table complètes (full table scans) sur tout ce qui dépassait un million de lignes. Après HNSW, c'est le jour et la nuit." -- datasci_pete, fil de discussion GitHub, pgvector/pgvector, fin 2023

À qui s'adresse pgvector

pgvector convient aux équipes qui utilisent déjà Postgres et souhaitent une recherche vectorielle sans ajouter de nouveau service à leur stack. Cela couvre une grande partie du marché des startups et des scale-ups : toute personne sur Supabase, Neon, RDS, Cloud SQL ou une instance Postgres auto-gérée peut activer pgvector avec une seule commande et commencer à stocker des embeddings le jour même. Il est adapté aux pipelines RAG, aux fonctionnalités de recherche sémantique, aux moteurs de recommandation et aux flux de travail de détection de doublons à des échelles allant jusqu'à environ 10 à 20 millions de vecteurs avec des performances de requête acceptables. Il est particulièrement bien adapté aux applications SaaS multi-locataires où les politiques de sécurité au niveau des lignes de Postgres offrent une isolation des données par client sans aucune couche de contrôle d'accès personnalisée dans la couche vectorielle. Les équipes disposant d'une bande passante DevOps limitée qui ne peuvent pas justifier la gestion d'un autre service stateful trouveront la simplicité opérationnelle de pgvector convaincante, même lorsque les chiffres de performance ne sont pas les meilleurs de leur catégorie.

Ce que pgvector n'est pas

pgvector n'est pas un remplacement pour les bases de données vectorielles spécialisées à grande échelle ou sous de lourdes charges d'écriture simultanées. À partir de 50 millions de vecteurs et plus, ou dans les applications où le magasin de vecteurs est interrogé des milliers de fois par seconde, la surcharge du planificateur de requêtes Postgres de pgvector et la concurrence basée sur MVCC deviennent des contraintes mesurables. Les équipes dans cette situation signalent systématiquement migrer vers Qdrant (auto-hébergé) ou Pinecone (géré) plutôt que d'essayer de contourner les limites de pgvector.

pgvector ne propose pas de recherche hybride native. Pour les pipelines RAG qui nécessitent un classement par mots-clés BM25 combiné à une similarité vectorielle (un modèle de plus en plus standard dans les systèmes de recherche en production en 2025-2026), vous devez assembler les pièces vous-même en utilisant la recherche plein texte de Postgres, pg_trgm ou un index BM25 externe, puis fusionner les scores dans le code de l'application. Des systèmes dédiés comme Weaviate et Elasticsearch proposent la recherche hybride comme un mode de premier ordre avec des paramètres alpha ajustables. Si la recherche hybride est au cœur de votre produit, pgvector nécessite une ingénierie supplémentaire significative pour égaler ce que les systèmes dédiés offrent clé en main.

pgvector ne vous sera d'aucune utilité non plus si votre application n'est pas sur Postgres. Si votre magasin de données principal est MongoDB, MySQL, Cassandra ou un pur magasin d'objets, pgvector n'est pas fait pour vous : vous avez besoin d'une base de données vectorielle dédiée ou d'un service géré.