pgvector
Définition
Extension PostgreSQL qui permet de stocker des embeddings et de faire de la recherche vectorielle directement dans la base. Inclus par défaut dans Supabase.
Comment ça marche
pgvector est une extension PostgreSQL qui ajoute un type de données vectoriel et les opérateurs de distance correspondants. On stocke les embeddings dans une colonne de type vector(dimension) comme une colonne classique. On les requête avec des opérateurs SQL : <-> pour la distance euclidienne, <#> pour la distance cosinus négative, <=> pour la distance cosinus. Une requête SELECT * FROM articles ORDER BY embedding <=> $1 LIMIT 5 ramène les 5 articles les plus proches sémantiquement de l'embedding $1. Le tout en SQL standard, sans changer de moteur ni de syntaxe.
L'intérêt face aux bases vectorielles dédiées
pgvector évite d'ajouter une base vectorielle dédiée (Pinecone, Weaviate, Qdrant) à votre stack. Les embeddings vivent à côté de vos données métier, dans la même base, avec les mêmes droits d'accès, le même backup, les mêmes migrations Drizzle ou Prisma. On peut joindre une recherche vectorielle avec un WHERE classique (filtrer par utilisateur, date, statut) en une seule requête : impossible avec une base vectorielle externe. Et on bénéficie de la maturité de PostgreSQL : ACID, monitoring, points de restauration, communauté. Pour la grande majorité des projets, c'est le bon défaut.
Les index HNSW et IVFFlat
Sans index, une recherche vectorielle sur 100 000 lignes prend plusieurs secondes : pgvector scanne tout. Avec un index HNSW (Hierarchical Navigable Small World), la même recherche descend à quelques millisecondes, avec une légère perte de précision configurable. HNSW est le choix par défaut depuis pgvector 0.5 : meilleure qualité de recherche, lecture rapide, construction plus longue. IVFFlat reste pertinent pour des volumes très importants où la construction d'index HNSW devient coûteuse. On choisit l'index selon le volume et le pattern d'écriture/lecture.
Les hébergeurs qui le proposent
Supabase l'inclut activé par défaut, sans configuration. Neon le propose en quelques clics. AWS RDS PostgreSQL le supporte depuis 2023. Render, Railway, Heroku Postgres l'ont. Sur un PostgreSQL auto-hébergé (Hetzner, OVH, Scaleway), il s'installe en une commande CREATE EXTENSION vector. C'est l'un des avantages de PostgreSQL : les extensions étendent ses capacités sans casser la compatibilité. Pour des contraintes de souveraineté, on peut donc faire du RAG complet sur infrastructure française avec une stack 100% PostgreSQL.
Quand l'utiliser
pgvector convient pour des volumes modestes à moyens : jusqu'à quelques millions de vecteurs avec des dimensions raisonnables (768 à 1536), il tient sans difficulté sur une machine standard avec les bons index. Au-delà, ou pour des besoins de filtrage très avancé (recherche multi-vecteur, filtres sur métadonnées en masse), on regarde Qdrant, Weaviate ou Pinecone. Pour un RAG d'entreprise avec quelques centaines de milliers de chunks, pour un moteur de recherche interne, pour des recommandations sur quelques millions d'articles, pgvector est largement suffisant et beaucoup plus simple à opérer qu'une base dédiée.
Les pièges à éviter
Quatre erreurs courantes. Stocker les embeddings sans index, ce qui rend la recherche linéaire en lignes : on crée un index HNSW dès qu'on dépasse quelques milliers de vecteurs. Choisir une dimension trop grande sans nécessité : un embedding à 3072 dimensions occupe 3 fois plus d'espace qu'un 1024, et la recherche est plus lente. Ignorer la normalisation : les opérateurs cosinus supposent des vecteurs normalisés, qu'on calcule à l'insertion. Et oublier le VACUUM : sur une table en forte écriture, les statistiques se dégradent, on configure autovacuum agressif. Bien configuré, pgvector tourne sans surprise pendant des années.