pgvector vs Pinecone vs Weaviate vs Qdrant : lequel choisir en 2026

pgvector, Pinecone, Weaviate et Qdrant répondent tous à la même fonction, trouver les vecteurs les plus proches d'une requête, avec des architectures incompatibles entre elles. Le tableau ci-dessous compare ce qui reste vrai dans la durée : modèle de déploiement, emplacement des données, capacités de recherche. Les prix et les numéros de version précis de Pinecone, Weaviate et Qdrant en sont volontairement absents : vérifiez-les sur les sites officiels avant toute décision d'achat.

Élément vérifié dans le code Aurabase : la version pgvector embarquée dans l'image Postgres de chaque projet est la 0.8.6. Elle est livrée par l'image CNPG standard en amont, pas ajoutée spécifiquement par Aurabase. Ce fait est constaté dans le Dockerfile du dépôt, le 23 août 2026. Le dépôt officiel pgvector confirme par ailleurs une dimension maximale de 16 000 par vecteur. C'est largement au-dessus des trois classes de dimensions (768, 1536, 3072) utilisées par le pipeline RAG natif d'Aurabase. Ce pipeline, lui, est un ajout applicatif propre à Aurabase, construit au-dessus de pgvector.

pgvector ajoute un type de colonne vector(n) et des opérateurs de distance (<=> cosinus, <-> euclidienne, <#> produit scalaire) à une base Postgres normale. Vos vecteurs partagent la même table, la même transaction et les mêmes contraintes que le reste de votre schéma : rien à synchroniser vers un système externe.

Pour la recherche approximative, pgvector propose deux types d'index au choix. IVFFlat découpe l'espace vectoriel en listes par clustering et cherche uniquement dans les listes les plus proches de la requête. Sa construction est plus légère, mais il faut choisir un nombre de listes adapté au volume de données. HNSW construit un graphe de voisins à plusieurs niveaux, sans étape d'entraînement préalable, au prix d'une construction plus coûteuse en mémoire. Pour le détail des paramètres de réglage (m, ef_construction), voir notre guide dédié à l'index HNSW.

-- Extension et colonne vecteur (dimension 1536, ex. text-embedding-3-small)
CREATE EXTENSION IF NOT EXISTS vector;
ALTER TABLE documents ADD COLUMN embedding vector(1536);
-- Index HNSW pour la recherche approximative
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
-- Recherche vectorielle jointe à une table relationnelle, filtrée par RLS
SELECT d.id, d.content
FROM documents d
JOIN projects p ON p.id = d.project_id
WHERE p.owner_id = auth.uid()
ORDER BY d.embedding <=> $1
LIMIT 5;

La dernière ligne est le point structurant : la clause WHERE p.owner_id = auth.uid() s'applique à la recherche vectorielle exactement comme à n'importe quelle autre requête. Aucune base vectorielle dédiée ne reproduit ce comportement nativement, puisque vos policies RLS vivent dans Postgres, pas dans un service tiers. Pour construire un pipeline RAG complet sur cette base, voir notre tutoriel pipeline RAG avec pgvector.

Pinecone est une base vectorielle proposée exclusivement en tant que service cloud propriétaire. Il n'existe pas de version auto-hébergeable publique : vos vecteurs vivent dans l'infrastructure de Pinecone, pas dans la vôtre. C'est un choix d'architecture assumé par l'éditeur, pas une limitation temporaire.

Le compromis est direct. Zéro opération d'infrastructure vectorielle à gérer : pas de cluster à dimensionner, pas d'index à faire tourner soi-même. En échange, deux coûts cachés apparaissent souvent après coup. D'abord, un pipeline de synchronisation à construire et maintenir entre votre base principale et l'index Pinecone, avec sa propre logique de cohérence en cas d'échec partiel. Ensuite, un format et une API propriétaires : migrer hors de Pinecone signifie réexporter l'intégralité des vecteurs et reconstruire l'intégration ailleurs.

Weaviate est une base vectorielle dédiée, open source et auto-hébergeable, également disponible en offre cloud managée (Weaviate Cloud) pour qui préfère ne pas l'opérer soi-même. Sa fonctionnalité la plus mise en avant par l'éditeur est la recherche hybride native. Elle fusionne, dans un seul classement de résultats, un score de similarité vectorielle et un score de correspondance mots-clés de type BM25.

Concrètement, cela évite d'écrire soi-même la logique de fusion entre recherche sémantique et recherche par mots-clés, une étape que d'autres approches laissent à la charge de l'application. Weaviate propose aussi un système de modules pour brancher directement des fournisseurs d'embeddings externes au moment de l'ingestion. Le compromis reste le même que pour toute base dédiée : un système supplémentaire à opérer ou à payer, à garder synchronisé avec votre source de données principale.

Qdrant est une base vectorielle dédiée, open source et écrite en Rust, elle aussi disponible en auto-hébergement ou en cloud managé (Qdrant Cloud). Comme le cœur d'Aurabase, Qdrant est écrit en Rust : un choix de langage partagé, pas un argument de supériorité en soi.

Deux points reviennent le plus souvent dans les retours d'expérience sur Qdrant. D'abord, un système de filtrage par payload riche : il permet de combiner filtres structurés (catégorie, date, statut) et recherche vectorielle dans la même requête. Ensuite, des options de quantification (scalaire ou binaire), destinées à réduire l'empreinte mémoire d'un index à grande échelle. Même compromis que Weaviate : un système distinct de votre base principale, avec sa propre logique de synchronisation à maintenir.

Aurabase n'ajoute pas pgvector : l'extension est déjà présente dans l'image Postgres standard fournie par CloudNativePG, la fondation utilisée pour les clusters tenant. Ce qu'Aurabase construit par-dessus, c'est la fonctionnalité applicative : un pipeline d'ingestion avec gestion des erreurs réseau, un module d'embeddings, et une recherche vectorielle par index HNSW. Cette capacité est exposée nativement dans le service aura-ai, vérifié dans le code du dépôt le 23 août 2026.

Le pipeline RAG d'Aurabase gère trois classes de dimensions d'embeddings (768, 1536, 3072), correspondant aux tailles de sortie les plus courantes des modèles d'embeddings actuels. Chaque vecteur reste une colonne d'une table Postgres normale, dans le schéma du projet, sous les mêmes policies RLS que le reste des données de ce projet. C'est la même logique que l'exemple SQL de la section 02, appliquée à un pipeline complet plutôt qu'à une requête isolée.

pgvector, Pinecone, Weaviate et Qdrant ne couvrent pas le même besoin. pgvector supprime la synchronisation en gardant les vecteurs dans Postgres, au prix d'un moteur moins spécialisé qu'un produit dédié. Pinecone retire toute opération d'infrastructure, contre un verrouillage propriétaire total. Weaviate ajoute une recherche hybride native prête à l'emploi. Qdrant met l'accent sur le filtrage riche et l'empreinte mémoire à grande échelle. Le critère qui tranche reste le même dans les quatre cas : où vos données doivent-elles vivre, et qui doit pouvoir les filtrer.

Pour construire un pipeline RAG complet sur cette base, notre tutoriel pipeline RAG avec pgvector détaille l'ingestion, les embeddings et la recherche vectorielle étape par étape. Pour la vue d'ensemble du pilier IA native d'Aurabase, voir la page IA native.