Base de données vectorielle en entreprise : pgvector vs Pinecone vs Qdrant — Guide complet 2026

#Pourquoi les bases vectorielles sont au cœur des systèmes IA

Les embeddings sont devenus la représentation universelle du sens dans les systèmes d'intelligence artificielle. Un modèle d'embedding transforme n'importe quel contenu — texte, image, audio, code — en un vecteur numérique dense dont la position dans l'espace à haute dimension encode la signification. Deux phrases sémantiquement proches produisent des vecteurs proches ; deux phrases opposées produisent des vecteurs éloignés. C'est sur cette propriété que repose toute l'infrastructure moderne des LLM appliqués à la donnée privée.

Le RAG (Retrieval-Augmented Generation) est aujourd'hui la technique dominante pour connecter un LLM aux connaissances d'une entreprise. Son moteur : une recherche dans une base vectorielle qui récupère les passages les plus pertinents pour enrichir le prompt du modèle. Sans base vectorielle performante, le RAG est borgne.

Les cas d'usage qui dépendent directement d'une base vectorielle sont nombreux et concrets :

• Search sémantique : trouver des documents pertinents sans correspondance exacte de mots-clés
• Recommandations : produits, articles, profils dont le profil vectoriel ressemble à celui de l'utilisateur
• Classification : rattacher automatiquement un document à une catégorie par proximité avec des exemples étiquetés
• Détection d'anomalies : identifier des transactions ou comportements dont le vecteur s'éloigne du cluster normal
• Déduplication : regrouper des fiches produits ou des leads dont les embeddings sont quasi-identiques

Le marché valide cet engouement : évalué à 1,5 milliard de dollars en 2025, il est attendu en croissance d'un facteur 4 entre 2026 et 2028 selon plusieurs analystes sectoriels. Ce n'est pas une mode technique — c'est l'infrastructure sous-jacente de l'ère des agents IA.

#Comment fonctionnent les embeddings et la recherche vectorielle

Un modèle d'embedding prend une entrée (une phrase, un paragraphe, une image) et produit un vecteur de taille fixe. Les dimensions courantes sont 768 (BERT-base, Mistral Embed), 1 536 (text-embedding-ada-002 d'OpenAI) et 3 072 (text-embedding-3-large d'OpenAI). Plus la dimension est élevée, plus le modèle peut encoder de nuances — au prix d'un coût mémoire et de calcul proportionnellement plus élevé.

#Les métriques de similarité

Trois distances sont utilisées pour comparer des vecteurs :

• Distance cosinus : mesure l'angle entre deux vecteurs indépendamment de leur norme. C'est la métrique par défaut pour les embeddings texte car deux phrases courtes et longues exprimant la même idée produisent des vecteurs de normes différentes mais d'angles proches.
• Distance L2 (euclidienne) : mesure la distance géométrique dans l'espace. Sensible à la norme des vecteurs, donc moins adaptée aux embeddings de longueurs variables.
• Produit scalaire (dot product) : rapide à calculer, utilisé quand les vecteurs sont normalisés (auquel cas il est équivalent à la similarité cosinus).

#ANN : la recherche approximative du plus proche voisin

Rechercher le vecteur le plus proche dans une base de 10 millions d'entrées en calculant toutes les distances un par un (brute force) prendrait des secondes. Les algorithmes ANN (Approximate Nearest Neighbor) permettent d'obtenir le résultat en quelques millisecondes en sacrifiant une petite fraction du recall :

• HNSW (Hierarchical Navigable Small World) : graph multi-couches qui navigue hiérarchiquement vers les voisins. Excellent recall, bonne latence de requête, mais empreinte mémoire élevée (le graph entier doit tenir en RAM).
• IVF (Inverted File Index) : partitionne l'espace vectoriel en clusters, ne cherche que dans les k clusters les plus proches. Économe en mémoire, légèrement moins précis.
• LSH (Locality-Sensitive Hashing) : projette les vecteurs dans des buckets de hachage. Simple et rapide, mais recall souvent inférieur aux deux précédents sur les données texte.

Le tradeoff fondamental : recall (% des vrais voisins retrouvés) vs latence (temps de réponse) vs coût mémoire. pgvector et Qdrant utilisent HNSW comme index par défaut ; Pinecone gère automatiquement ce choix selon la taille de l'index.

#pgvector : PostgreSQL comme base vectorielle

pgvector est une extension open source qui ajoute à PostgreSQL un type de données vector, des opérateurs de similarité et des index optimisés (HNSW et IVF). Sa proposition de valeur tient en une phrase : si vous êtes déjà sur PostgreSQL, vous avez une base vectorielle en une commande CREATE EXTENSION vector;.

#Ce que pgvector apporte nativement

• Intégration PostgreSQL complète : requêtes vectorielles mélangées avec des jointures relationnelles, transactions ACID, Row Level Security pour le multi-tenant, logique métier SQL existante.
• Hybrid search : combinaison native de full-text search (tsvector) et de recherche vectorielle dans la même requête.
• HNSW et IVF indexing : depuis la version 0.5, pgvector supporte HNSW ce qui l'a rendu compétitif sur la latence.
• Zéro nouvelle infrastructure : pas de nouveau service à opérer, pas de base de données supplémentaire, backup inclus dans le backup PostgreSQL existant.

#Les limites réelles de pgvector

Pgvector n'est pas une base vectorielle native. Au-delà de 10 millions de vecteurs, les performances de construction d'index et de requête commencent à décrocher par rapport aux solutions dédiées. La latence de requête reste plus élevée que Pinecone ou Qdrant à grande échelle, notamment quand de nombreuses requêtes concurrentes s'exécutent simultanément.

#Quand pgvector suffit

• Corpus inférieur à 5 millions de vecteurs
• Stack PostgreSQL déjà en production (RDS, Supabase, Neon, OVH Managed PostgreSQL)
• Contraintes RGPD et hosting souverain : pgvector sur OVH ou Scaleway permet un pipeline 100 % européen
• Équipe sans spécialiste ops — la courbe d'apprentissage est quasi nulle
• Projets RAG qui bénéficient du filtrage relationnel natif (requêtes du type : vecteurs similaires parmi les documents de ce client et signés après cette date)

#Pinecone : la référence SaaS vectorielle

Pinecone a popularisé la catégorie des bases vectorielles dédiées en proposant une expérience SaaS entièrement managée avec une DX soignée. Sa promesse : une latence inférieure à 10 ms à n'importe quelle échelle, sans aucune gestion d'infrastructure.

#Architecture et fonctionnalités

L'architecture serverless de Pinecone sépare stockage et calcul, permettant un auto-scaling transparent. Les fonctionnalités clés :

• Namespaces : isolation logique des données pour le multi-tenancy (ex : un namespace par client SaaS)
• Metadata filtering : filtrages par champs attributs (date, catégorie, auteur) sans dégradation de performance
• Hybrid search : support natif dense + sparse (BM25 via l'index Pinecone sparse-dense)
• SLA 99,95 % et monitoring intégré

#Quand choisir Pinecone

Pinecone est pertinent pour des corpus supérieurs à 5 millions de vecteurs où l'équipe ne veut pas gérer d'infrastructure, avec un besoin de haute disponibilité critique et un time-to-market court. C'est la solution la plus rapide à mettre en production pour une équipe sans ops.

#Les limites à connaître

• SaaS américain : les données transitent et résident sur des serveurs AWS US East par défaut. Cela soulève des questions RGPD non triviales pour des données personnelles ou confidentielles. Les transferts hors UE nécessitent des clauses contractuelles spécifiques (SCCs) et une analyse de risque.
• Coût à grande échelle : la facturation par pod/namespace peut devenir significative au-delà de 50 millions de vecteurs. Certains clients Nehos ont migré de Pinecone vers Qdrant self-hosted après 18 mois pour réduire leur facture infrastructure de 60 à 70 %.
• Pas d'option on-premise : pour les entreprises soumises à des exigences de souveraineté strictes (HDS, SecNumCloud), Pinecone est exclu.

#Weaviate, Qdrant, Milvus : les alternatives à connaître

L'écosystème des bases vectorielles s'est considérablement étoffé. Voici les alternatives majeures à pgvector et Pinecone.

#Weaviate — La plus complète pour les pipelines hybrides

Weaviate se distingue par son support natif du hybrid search (dense + BM25), ses modules d'inférence embarqués (vous pouvez lui passer des textes bruts, il génère les embeddings en interne), et ses capacités orientées graphe pour relier des entités sémantiquement liées. Elle est disponible en open source (Docker, Kubernetes) et en cloud managé. Pertinente pour les architectures complexes qui mixent plusieurs types de données et nécessitent un raisonnement sur des entités liées.

#Qdrant — La référence on-premise

Écrite en Rust, Qdrant est la solution que Nehos recommande pour les déploiements souverains avec des volumes dépassant 1 million de vecteurs. Ses atouts :

• Filtrage de payload très performant : chercher dans un sous-ensemble de vecteurs par attribut métadonnée sans dégradation notable de la latence
• Scalar quantization et binary quantization pour réduire l'empreinte mémoire jusqu'à 32×
• API REST et gRPC propres, SDK Python/TypeScript maintenus
• Déploiement simple via Docker ou Helm chart Kubernetes
• Benchmarks publics disponibles sur qdrant.tech qui montrent des performances supérieures à Pinecone sur certaines workloads de filtrage

#Milvus — Pour les très grands volumes

Milvus est conçu pour les corpus de l'ordre du milliard de vecteurs, avec une architecture cloud-native Kubernetes, une séparation stockage/calcul et un support multi-index sophistiqué. C'est la solution la plus scalable de la catégorie — et aussi la plus complexe à opérer. Pertinente pour les acteurs qui gèrent des volumes que pgvector et Qdrant ne peuvent pas atteindre.

#ChromaDB — Pour le prototypage

ChromaDB est le choix pragmatique pour les PoC et le développement local. Installation en une ligne, API Python simple, embarquable directement dans le process Python. Elle ne convient pas à la production au-delà de quelques millions de vecteurs.

#Tableau comparatif sur 8 critères

→ Vous évaluez vos options ? Utilisez notre estimateur de budget en ligne pour obtenir une fourchette en 2 minutes, ou consultez nos tarifs détaillés.

#Hybrid search : sparse + dense

La recherche vectorielle pure a une faiblesse structurelle : elle raisonne par analogie sémantique mais manque les correspondances exactes. Cherchez "contrat référence AO-2024-0387" dans une base vectorielle : si ce code d'appel d'offres n'apparaît pas verbatim dans les chunks, le modèle d'embedding ne le retrouvera pas. C'est le problème des noms propres, des codes produits, des références contractuelles, des numéros de version.

Le hybrid search résout cela en combinant deux signaux complémentaires :

• Dense retrieval (embeddings) : capture la proximité sémantique, les synonymes, les paraphrases
• Sparse retrieval (BM25) : capture les correspondances exactes de termes, les codes, les acronymes

#Score fusion : Reciprocal Rank Fusion

Les deux listes de résultats sont fusionnées via Reciprocal Rank Fusion (RRF). Pour chaque document, le score RRF est calculé comme la somme des inverses de son rang dans chaque liste : score_RRF = 1/(k + rank_dense) + 1/(k + rank_sparse) avec k généralement fixé à 60. Ce mécanisme est robuste et ne nécessite pas de normalisation des scores entre les deux modalités.

#Implémentations concrètes

• pgvector + pg_fulltext : requête SQL combinant <-> (distance vectorielle) et @@ (full-text), avec ts_rank pour le score BM25, fusionnés manuellement en SQL ou via une couche applicative
• Weaviate hybrid : API hybrid: { query, alpha } où alpha contrôle le poids dense/sparse
• Pinecone hybrid : index dense-sparse séparés interrogés simultanément, fusion côté serveur

#Cas d'usage : recherche catalogue produits B2B avec codes EAN

Un distributeur B2B avec 200 000 références produits bénéficie directement du hybrid search : la recherche "câble USB-C 2m noir certifié" trouve les produits sémantiquement proches (dense), tandis qu'une recherche par code EAN exact (sparse) retourne immédiatement la fiche précise. Sur un déploiement Nehos, le passage au hybrid search a augmenté le recall@10 de 71 % à 89 % sur ce type de corpus.

#Chunking et ingestion de documents

Le choix de la base vectorielle ne compte que si le corpus est bien préparé. La stratégie de chunking est souvent le facteur le plus impactant sur la qualité finale du RAG.

#Stratégies de chunking

Fixed size chunking : découpe le texte en segments de 400 à 600 tokens avec un overlap de 20 % (80-120 tokens). Simple à implémenter, robuste sur des corpus hétérogènes. L'overlap garantit que les informations à la frontière entre deux chunks ne sont pas perdues.

Semantic chunking : découpe aux frontières de paragraphes ou de phrases en utilisant un modèle de segmentation. Préserve l'unité logique du texte. Résultats supérieurs sur des documents bien structurés (articles, rapports, documentation technique).

Hierarchical chunking : produit plusieurs niveaux de granularité pour le même document — document entier → section → paragraphe. Permet des requêtes à l'échelle du document (résumé) et à l'échelle du fragment (détail précis). Architecture plus complexe mais recall amélioré sur les requêtes générales.

#Enrichissement des métadonnées

Chaque chunk doit embarquer des métadonnées structurées pour permettre le filtrage :

• source : nom du fichier ou URL d'origine
• date : date de création ou de dernière modification du document
• author : auteur du document
• category : catégorie métier (contrat, procédure, jurisprudence...)
• access_level : niveau d'accès (public, interne, confidentiel) pour l'implémentation du RBAC
• document_id : identifiant unique pour le regroup des chunks d'un même document

Sans ces métadonnées, la base vectorielle ne peut pas répondre à des requêtes comme «trouve les contrats de ce client signés après 2024».

#Reranking post-retrieval

Après la récupération des k chunks candidats, un modèle de reranking (Cohere Rerank, BGE Reranker, Mistral Rerank) réordonne les résultats selon leur pertinence précise pour la requête. Ce modèle cross-encoder est plus coûteux qu'un embedding mais est appliqué uniquement sur les k=20 candidats retenus — et peut augmenter la précision@5 de 10 à 20 points de pourcentage.

#Pipeline complet d'ingestion

Fichiers (PDF, Word, HTML, email)
  → Parsing (Unstructured.io, PyMuPDF, BeautifulSoup)
  → Nettoyage (déduplication, normalisation encodage)
  → Chunking (LangChain RecursiveCharacterTextSplitter ou semantic)
  → Enrichissement métadonnées
  → Embedding (OpenAI text-embedding-3-large ou Mistral Embed)
  → Stockage (pgvector / Qdrant / Pinecone)
  → Indexation HNSW (batch ou progressive)

#Architecture production recommandée par Nehos

Après plusieurs dizaines de projets RAG déployés en production, Nehos a convergé vers deux architectures de référence selon le volume et les contraintes de souveraineté.

#Stack <5 millions de vecteurs (souverain)

• Base vectorielle : PostgreSQL 16 + pgvector sur OVH Managed PostgreSQL ou Supabase EU
• Pipeline d'ingestion : LangChain + Unstructured.io pour le parsing multiformat
• Modèle d'embedding : text-embedding-3-large (OpenAI) pour la performance maximale, ou Mistral Embed pour une solution 100 % européenne
• API : NestJS avec cache Redis sur les requêtes fréquentes
• Frontend : Next.js avec streaming des réponses (Server-Sent Events)
• Orchestration RAG : LlamaIndex pour la gestion des pipelines de retrieval

#Stack >5 millions de vecteurs (on-premise ou cloud souverain)

• Base vectorielle : Qdrant self-hosted sur Kubernetes (OVH Managed Kubernetes ou Scaleway Kapsule)
• Pipeline d'ingestion : LangChain + Unstructured.io + Kafka pour l'ingestion en continu depuis les sources documentaires (SharePoint, S3, webhooks)
• Modèle d'embedding : Mistral Embed ou bge-m3 (multilingue, excellent sur le français) hébergé en self-hosted
• Reranking : BGE Reranker v2 self-hosted pour rester dans le périmètre souverain
• API : NestJS + GraphQL pour les requêtes complexes multi-sources
• Frontend : Next.js 16 avec streaming

#Monitoring et observabilité

Un pipeline RAG en production doit monitorer en continu :

• Latence P95 de la chaîne complète (embedding requête + retrieval + génération) — cible : <2 secondes
• Recall@K mesuré sur un jeu de test représentatif mis à jour mensuellement
• Freshness des embeddings : détecter les documents mis à jour non ré-indexés
• Score de faithfulness (RAGAS) sur un échantillon de requêtes réelles pour détecter les dérives du modèle
• Alertes LangFuse ou Arize Phoenix quand le score moyen de pertinence descend sous le seuil défini

#Stratégie de migration pgvector → Qdrant

La migration est déclenchée quand : les requêtes P95 dépassent 500 ms de manière répétée, ou quand le volume dépasse 8 millions de vecteurs. La procédure : export des vecteurs + métadonnées depuis pgvector, import progressif dans Qdrant (collection shadow), basculement Blue/Green avec lecture en parallèle pendant 48 heures, puis coupure définitive. Aucune perte de données, temps d'arrêt nul sur les projets Nehos.

#Cas Nehos : base de connaissances juridique sur 50 000 documents

#Le contexte client

Un cabinet de conseil opérant en France gérait 50 000 documents juridiques : contrats clients, jurisprudence, textes de loi, notes d'analyse interne. La recherche full-text existante (Elasticsearch) permettait de retrouver des documents par mots-clés exacts, mais échouait sur les requêtes sémantiques — le type même des questions posées par les consultants : «Quels contrats contiennent des clauses de limitation de responsabilité similaires à celle signée avec Acme Corp ?»

#Phase 1 : pgvector (corpus 3 millions de chunks)

Le corpus initial a été découpé en 3 millions de chunks (2 800 documents × environ 1 000 chunks par document en moyenne). Le modèle d'embedding choisi : text-embedding-3-large d'OpenAI (3 072 dimensions) — optimal pour la précision juridique en français. La base a été déployée sur PostgreSQL 16 + pgvector, hébergé sur OVH (France, conformité RGPD confirmée).

Résultats à 30 jours :

• Recall@5 : 87 % vs 67 % avec la recherche full-text précédente
• Temps de réponse moyen : 380 ms (P95 : 850 ms)
• Adoption utilisateur : 78 % des consultants utilisent quotidiennement l'outil

#Phase 2 : migration vers Qdrant (corpus 8 millions de chunks)

Avec l'intégration de nouvelles sources documentaires (archives historiques, jurisprudence internationale, bases réglementaires UE), le corpus est passé à 8 millions de chunks. Les requêtes P95 de pgvector atteignaient régulièrement 1,2 secondes — au-delà du seuil accepté.

Migration vers Qdrant self-hosted sur Kubernetes (OVH), avec activation du hybrid search (BM25 + dense) et du reranking BGE Reranker v2. Configuration : scalar quantization Int8 pour réduire l'empreinte mémoire de 4×, HNSW ef=256 pour un recall maximal.

Résultats finaux après optimisation :

• Recall@5 : 94 % (vs 67 % full-text initial, +27 points)
• Temps de réponse P95 : 180 ms (objectif : <200 ms)
• 0 perte de données lors de la migration (procédure Blue/Green)
• Coût infrastructure mensuel : 40 % inférieur à une solution Pinecone équivalente

Ce projet illustre la trajectoire naturelle recommandée par Nehos pour les bases de connaissances d'entreprise : démarrer avec pgvector pour la simplicité opérationnelle, puis migrer vers Qdrant quand les volumes et les exigences de performance le nécessitent — sans jamais sacrifier la souveraineté des données.