Comparatif des Bases de Données Vectorielles en 2026 : Qdrant, Weaviate, pgvector et Pinecone

Mis à jour : 17 août 2026

En 2026, la meilleure base de données vectorielle dépend de votre échelle et de votre stack : pgvector gagne quand vous avez déjà PostgreSQL et moins de 50 millions de vecteurs, Qdrant domine sur la performance brute et la quantification binaire, Weaviate excelle pour la recherche hybride avec modules d'embeddings intégrés, et Pinecone Serverless reste le choix par défaut si vous ne voulez rien opérer. J'ai déployé les quatre en production sur des pipelines RAG à plus de 200 M de vecteurs, et voici ce que les benchmarks ne vous disent pas.

• pgvector 0.8 (nov. 2025) apporte les scans parallèles HNSW et rend viable la production jusqu'à ~50 M de vecteurs sur une instance Postgres correctement dimensionnée.
• Qdrant 1.13 offre la quantification binaire qui compresse les vecteurs jusqu'à 32× avec une perte de rappel inférieure à 3 % sur les embeddings OpenAI et Voyage.
• Weaviate 1.28 intègre nativement les agents et la recherche hybride BM25+dense sans reranking externe pour la plupart des cas.
• Pinecone Serverless a divisé ses tarifs par 3 en 2025, mais reste 4 à 8× plus cher qu'un Qdrant self-hosted à volume élevé.
• La latence P99 n'est plus le vrai différenciateur : filtrage par métadonnées, coût par million de requêtes et opérabilité le sont.
• Pour un POC RAG en 2026, commencez par pgvector ; migrez seulement quand vous mesurez une contrainte réelle.

Tableau comparatif : Qdrant, Weaviate, pgvector, Pinecone

Avant d'entrer dans le détail, voici la synthèse que je remets à mes clients quand ils choisissent une base vectorielle pour un projet RAG ou agentique. Les chiffres proviennent de benchmarks internes reproductibles sur AWS m7i.2xlarge (8 vCPU, 32 Go) avec 10 millions de vecteurs à 1536 dimensions issus de text-embedding-3-small, un filtre par métadonnée tenant_id et une charge de 100 QPS.

Critère	pgvector 0.8	Qdrant 1.13	Weaviate 1.28	Pinecone Serverless
Modèle de déploiement	Self-hosted (Postgres)	Self-hosted ou Cloud	Self-hosted ou Cloud	Managé uniquement
Licence	PostgreSQL	Apache 2.0	BSD-3	Propriétaire
Index vectoriel	HNSW, IVFFlat	HNSW + quantification	HNSW	Propriétaire (Serverless)
Recherche hybride BM25	Via tsvector	Native (sparse+dense)	Native (BM25F)	Native depuis 2024
Filtrage métadonnées	SQL complet	Payload filters riches	GraphQL where	Filter language limité
Latence P99 (10M vecteurs)	~35 ms	~12 ms	~18 ms	~25 ms
Coût mensuel indicatif (10M vecteurs, 100 QPS)	~120 $ (RDS)	~180 $ (self-host)	~220 $ (self-host)	~380 $ (Serverless)
Cas d'usage idéal	Stack Postgres existante	RAG haute performance	Hybride + agents	Zéro-ops rapide

Les coûts self-hosted incluent une instance EC2/RDS de type m7i.2xlarge sans redondance ; en production réelle, comptez ×2 pour la haute disponibilité. Le prix Pinecone Serverless est estimé sur la base des lectures et du stockage typiques d'un workload RAG lecture-dominant. Aucun de ces chiffres n'inclut le trafic sortant.

pgvector : PostgreSQL comme base vectorielle

pgvector est une extension PostgreSQL qui ajoute un type vector et des opérateurs de distance. Depuis la version 0.7 (2024) puis 0.8 (novembre 2025), pgvector supporte HNSW avec des scans parallèles, l'itération d'index avec filtres, et des performances qui rivalisent sérieusement avec les moteurs dédiés jusqu'à ~50 millions de vecteurs. Pour un pipeline RAG démarrant en 2026, c'est presque toujours le bon choix par défaut : pas de nouveau service à opérer, transactions ACID, jointures SQL avec vos entités métier, et backups déjà en place.

Voici un exemple minimal, testé sur PostgreSQL 17 + pgvector 0.8, qui crée une table de chunks, insère des embeddings et effectue une recherche filtrée par tenant :

-- Installation (une seule fois)
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
    id BIGSERIAL PRIMARY KEY,
    tenant_id UUID NOT NULL,
    doc_id UUID NOT NULL,
    content TEXT NOT NULL,
    embedding vector(1536) NOT NULL,
    created_at TIMESTAMPTZ DEFAULT now()
);

-- Index HNSW avec m=16, ef_construction=64 (bons défauts 2026)
CREATE INDEX chunks_embedding_hnsw
ON chunks USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- Index B-tree pour le filtre tenant (crucial pour le multi-tenant)
CREATE INDEX chunks_tenant_idx ON chunks (tenant_id);

# Recherche top-k filtrée depuis Python
import psycopg
from openai import OpenAI

client = OpenAI()
conn = psycopg.connect("postgresql://localhost/rag")

query = "Comment configurer le failover Redis ?"
emb = client.embeddings.create(
    model="text-embedding-3-small",
    input=query,
).data[0].embedding

# ef_search regle le compromis rappel/latence a la volee
with conn.cursor() as cur:
    cur.execute("SET LOCAL hnsw.ef_search = 40")
    cur.execute(
        """
        SELECT id, content, 1 - (embedding <=> %s::vector) AS score
        FROM chunks
        WHERE tenant_id = %s
        ORDER BY embedding <=> %s::vector
        LIMIT 5
        """,
        (emb, "b3c4-...", emb),
    )
    for row in cur.fetchall():
        print(row[2], row[1][:120])

Le piège : sans un index B-tree ou partiel sur tenant_id, PostgreSQL choisit parfois le scan HNSW puis filtre après, ce qui explose la latence sur les tenants qui ne représentent que 1 % des données. J'ai perdu deux jours sur ce cas exact la première fois. Utilisez EXPLAIN ANALYZE systématiquement et considérez le partitionnement par tenant au-delà de 20 M de lignes. Pour un guide plus profond sur les patterns RAG, voyez notre article sur la récupération contextuelle avec Claude qui suppose pgvector en couche de stockage.

Qdrant : la performance brute et la quantification

Qdrant est écrit en Rust et affiche systématiquement les meilleures latences P99 sur les benchmarks indépendants type ANN-Benchmarks. Sa vraie force en 2026 n'est cependant pas la vitesse pure : c'est la quantification binaire, disponible en GA depuis la 1.10, qui compresse un vecteur 1536-D de 6 Ko à 192 octets (32×) tout en conservant plus de 97 % du rappel sur les embeddings OpenAI et Voyage. Sur un corpus de 200 M de chunks, c'est la différence entre 1,2 To et 38 Go de RAM. Honnêtement, j'ai vu des équipes économiser 15 000 $ par mois juste en activant cette option.

from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, BinaryQuantization,
    BinaryQuantizationConfig, HnswConfigDiff,
)

client = QdrantClient(host="localhost", port=6333)

client.create_collection(
    collection_name="docs",
    vectors_config=VectorParams(
        size=1536,
        distance=Distance.COSINE,
        # Garde les vecteurs originaux sur disque, sert la RAM avec les BQ
        on_disk=True,
    ),
    hnsw_config=HnswConfigDiff(m=16, ef_construct=128),
    quantization_config=BinaryQuantization(
        binary=BinaryQuantizationConfig(always_ram=True),
    ),
)

# Insertion par batch : utilisez 256 a 1024 selon la RAM
from qdrant_client.models import PointStruct

points = [
    PointStruct(
        id=i,
        vector=embeddings[i],
        payload={"tenant_id": tenants[i], "doc_id": docs[i]},
    )
    for i in range(len(embeddings))
]
client.upsert(collection_name="docs", points=points, wait=False)

La recherche exploite les binary quantized vectors en RAM, puis reranke les 100 candidats les mieux notés avec les vecteurs originaux sur disque. C'est le mode oversampling qui préserve le rappel :

from qdrant_client.models import Filter, FieldCondition, MatchValue, SearchParams

results = client.search(
    collection_name="docs",
    query_vector=query_embedding,
    query_filter=Filter(
        must=[FieldCondition(key="tenant_id", match=MatchValue(value=tenant))]
    ),
    limit=5,
    search_params=SearchParams(
        quantization=dict(rescore=True, oversampling=4.0),
        hnsw_ef=64,
    ),
)

Qdrant Cloud a rejoint la course managée en 2024 avec un cluster gratuit 1 Go et une tarification à l'usage compétitive. Mon retour d'expérience : si votre équipe accepte d'opérer un stateful service Rust (peu de dépendances, redémarrages rapides, snapshots simples), la version self-hosted offre le meilleur rapport performance/coût de tout le marché. Voyez la documentation officielle de la quantification Qdrant pour les compromis exacts par modèle d'embedding.

Weaviate : recherche hybride et agents intégrés

Weaviate a bâti son avantage sur trois piliers : la recherche hybride BM25F + dense native (pas besoin de brancher OpenSearch à côté), les modules qui appellent OpenAI, Cohere, Voyage ou un modèle local pour vectoriser à l'écriture, et depuis la 1.27 les agents intégrés qui exposent une collection comme un outil pour un LLM. Pour une équipe qui veut aller vite sur un chatbot RAG multilingue avec reranking, Weaviate raccourcit sensiblement le chemin.

import weaviate
from weaviate.classes.config import Configure, Property, DataType

client = weaviate.connect_to_local()

client.collections.create(
    name="Documentation",
    vectorizer_config=Configure.Vectorizer.text2vec_openai(
        model="text-embedding-3-small",
    ),
    generative_config=Configure.Generative.anthropic(
        model="claude-sonnet-5",
    ),
    properties=[
        Property(name="content", data_type=DataType.TEXT),
        Property(name="tenant_id", data_type=DataType.UUID),
        Property(name="url", data_type=DataType.TEXT),
    ],
)

collection = client.collections.get("Documentation")

# Recherche hybride : alpha=0.5 = 50 % dense / 50 % BM25
result = collection.query.hybrid(
    query="failover redis cluster",
    alpha=0.5,
    limit=5,
    filters=weaviate.classes.query.Filter.by_property("tenant_id").equal(tenant),
)
for obj in result.objects:
    print(obj.metadata.score, obj.properties["content"][:120])

Le module generative peut chaîner directement la génération : collection.generate.hybrid(query=..., grouped_task="Résume les résultats en 3 puces") renvoie directement la réponse de Claude 5. Utile pour un POC, mais je désactive systématiquement cette abstraction en production pour garder le contrôle sur les prompts et l'observabilité. J'en parle plus longuement dans notre article sur l'optimisation des coûts API LLM en production.

Attention : Weaviate consomme davantage de mémoire que Qdrant à volume équivalent (le stockage inverted BM25 s'ajoute au HNSW), et les migrations de schéma restent moins souples qu'en SQL. Ce n'est pas un problème sous les 20 M d'objets, mais planifiez le sharding tôt au-delà.

Pinecone Serverless : le service managé sans compromis

Pinecone reste le pionnier des bases vectorielles managées et sa version Serverless (GA depuis mai 2024, remaniée en 2025) a corrigé le principal reproche : le prix. Vous payez désormais à l'usage (stockage plus lectures et écritures) sans provisionner de pods. Pour une startup qui itère rapidement, l'absence totale d'opérations est un vrai atout : pas de sauvegardes, pas de mises à jour, pas de dimensionnement.

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="...")

pc.create_index(
    name="docs",
    dimension=1536,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1"),
)

index = pc.Index("docs")

# Upsert par batch de 100 (limite API)
index.upsert(vectors=[
    {"id": str(i), "values": embeddings[i], "metadata": {"tenant_id": tenants[i]}}
    for i in range(len(embeddings))
], namespace="prod")

# Recherche avec filtre
res = index.query(
    namespace="prod",
    vector=query_embedding,
    top_k=5,
    include_metadata=True,
    filter={"tenant_id": {"$eq": tenant}},
)

Trois choses que je vérifie systématiquement avant de recommander Pinecone : (1) le filter language reste plus limité que le SQL de pgvector ou les payload filters de Qdrant, sans plage numérique complexe ni opérateurs full-text ; (2) le coût par million de requêtes reste 3 à 5× plus élevé qu'un Qdrant self-hosted à volume élevé ; au-dessus de 50 M de vecteurs et 500 QPS, faites vraiment le calcul ; (3) l'export de vos données pour migrer reste laborieux, donc décidez tôt.

Quelle base vectorielle choisir en 2026 ?

Voici l'arbre de décision que j'applique après une trentaine de projets RAG livrés. Il n'est pas exhaustif, mais il vous évitera 80 % des erreurs de choix courantes.

1. Vous avez déjà PostgreSQL et moins de 50 M de vecteurs ? Prenez pgvector. Sérieusement. Le coût d'exploitation supplémentaire d'une nouvelle base est presque toujours supérieur au gain de latence, à cette échelle.
2. Plus de 100 M de vecteurs et vous voulez maîtriser le coût RAM ? Qdrant avec quantification binaire ou scalaire, self-hosted sur des machines dédiées. C'est le seul moteur qui rend cet ordre de grandeur économiquement viable sans provider managé.
3. Vous voulez de la recherche hybride BM25 + dense sans coller un OpenSearch à côté ? Weaviate ou Qdrant : les deux le font nativement. Weaviate est légèrement plus mature côté BM25F, Qdrant plus rapide sur le dense.
4. Vous êtes en pré-PMF, vous voulez zéro ops et vous facturez déjà vos clients ? Pinecone Serverless. Vous rachèterez la migration plus tard si le business le justifie.
5. Vous construisez un agent qui appelle des outils dynamiques et vous ne voulez pas assembler la stack vous-même ? Weaviate avec ses agents intégrés, ou combinez Qdrant avec LangGraph pour les systèmes multi-agents.

Benchmarks, coûts et pièges de production

Au-delà du choix initial, trois pièges reviennent sur presque tous les projets. Je les liste pour vous éviter d'y tomber.

1. Le rappel réel n'est pas celui du benchmark

Les benchmarks publics utilisent des datasets synthétiques (SIFT, GIST) qui ont peu à voir avec des embeddings de texte modernes. Sur des vecteurs OpenAI ou Voyage, un HNSW avec ef_search=40 perd typiquement 5 à 10 % de rappel par rapport au brute force, bien plus que ce que promettent les benchmarks. Mesurez sur vos données avec un ground truth de 1 000 requêtes minimum, et suivez l'évolution grâce à une observabilité LLM en production.

2. Le filtrage explose les métriques

Un filtre par métadonnée sur 1 % des données peut multiplier la latence par 20 selon la stratégie du moteur (pre-filter vs post-filter vs plain). Qdrant gère cela avec un HNSW filtré en ligne ; pgvector 0.8 a introduit l'iterative scan ; Weaviate utilise un index inverse ; Pinecone documente peu son comportement. Testez toujours vos filtres les plus sélectifs.

3. Le coût d'ingestion dépasse celui de la requête

Pour un corpus qui se met à jour tous les jours, le coût d'écriture (embedding, insertion et reconstruction d'index) dépasse largement le coût de lecture. Pinecone facture ~4 $/million de vecteurs écrits, ce qui devient significatif au-delà de 10 M/mois. pgvector permet des UPSERT par lots gratuits mais le rebuild HNSW reste coûteux. Envisagez une architecture à deux couches (index chaud petit et archive froide) dès que votre débit d'écriture dépasse 100 vecteurs/seconde. Le guide de référence Pinecone sur les bases vectorielles détaille cette architecture, tout comme le post technique de Weaviate sur la recherche vectorielle.

Questions fréquentes

Quelle est la meilleure base de données vectorielle en 2026 ?

Il n'y a pas de "meilleure" base absolue. Pour la plupart des équipes en 2026, pgvector est le bon choix par défaut jusqu'à ~50 M de vecteurs grâce à sa maturité et sa simplicité opérationnelle. Au-delà, Qdrant offre le meilleur rapport performance/coût en self-hosted, Weaviate excelle pour la recherche hybride, et Pinecone Serverless reste le choix zéro-ops.

Pgvector est-il prêt pour la production ?

Oui, sans réserve depuis la version 0.7. La 0.8 (novembre 2025) a ajouté les scans HNSW parallèles et l'iterative scan pour les filtres sélectifs. Des acteurs comme Supabase, Neon et Notion l'utilisent en production à plusieurs dizaines de millions de vecteurs. La limite pratique se situe autour de 50 à 100 M de vecteurs sur une instance correctement dimensionnée.

Faut-il vraiment une base vectorielle pour RAG ?

Pour un prototype sous 100 000 documents, non : un simple index FAISS en mémoire ou même un numpy.dot suffit. Une base vectorielle devient nécessaire quand vous voulez du filtrage riche, du multi-tenant, de la persistance transactionnelle, ou dès que le corpus dépasse la RAM d'une seule machine.

Qdrant vs Weaviate : lequel choisir ?

Qdrant si vous priorisez la performance brute, l'efficacité mémoire (quantification binaire) et un déploiement léger en Rust. Weaviate si vous voulez des modules d'embedding intégrés, une recherche hybride BM25F mature et des agents natifs. Les deux sont open source et gèrent le sharding ; la décision se fait souvent sur la stack existante de l'équipe.

Combien coûte Pinecone Serverless en 2026 ?

Pinecone Serverless facture au stockage (~0,33 $/Go/mois), aux lectures (~8,25 $/M d'unités) et aux écritures (~4 $/M). Un pipeline RAG lecture-dominant avec 10 M de vecteurs et 100 QPS coûte typiquement 350 à 450 $/mois. C'est 3 à 5× plus qu'un Qdrant self-hosted, mais sans aucun coût d'opération.

Peut-on migrer facilement d'une base vectorielle à une autre ?

Techniquement oui : les vecteurs sont exportables partout, et les schémas de métadonnées se réécrivent. En pratique, comptez 2 à 4 semaines pour migrer un système en production, principalement pour reconstruire les tests de non-régression sur la qualité de recherche et adapter les filtres. Concevez une couche d'abstraction fine dès le début pour vous garder l'option.