Vector DB pour 1M de docs : pgvector ou Qdrant, ce qu'on choisirait aujourd'hui

La question revient sur tous les projets RAG dès qu'on commence à parler de passage à l'échelle : est-ce qu'on reste sur pgvector dans Postgres, ou est-ce qu'on passe sur une base vectorielle dédiée comme Qdrant ?

La réponse dépend de votre situation, mais la situation est souvent mal posée. On voit beaucoup d'équipes choisir l'une ou l'autre solution sur la base de benchmarks qu'elles n'ont pas faits elles-mêmes, ou sur des critères qui ne correspondent pas à leur cas d'usage réel.

Voici notre lecture après avoir utilisé les deux en production.

Les paramètres du problème

On parle d'un corpus d'un million de documents. Des chunks de texte de 300 à 600 tokens. Des vecteurs de dimension 1536 (OpenAI text-embedding-3-small) ou 1024 (BGE-M3). Des requêtes de recherche avec un objectif de latence P95 sous 200ms. Une infrastructure qui tourne déjà sur Postgres pour les données transactionnelles.

Ce contexte est important parce que les recommandations changent radicalement selon que vous partez de zéro ou que vous avez déjà un Postgres en production.

pgvector : forces réelles et limites réelles

Ce que pgvector fait bien

L'argument numéro un pour pgvector n'est pas technique : c'est opérationnel. Si vous avez déjà Postgres, vous n'ajoutez pas un service, pas un système de backup supplémentaire, pas une couche d'authentification à gérer. Vous activez une extension.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
    id BIGSERIAL PRIMARY KEY,
    content TEXT NOT NULL,
    embedding vector(1536),
    metadata JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Index HNSW (pgvector >= 0.5.0)
CREATE INDEX ON documents 
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

La jointure avec vos données métier est native. Un RAG qui doit filtrer les documents par tenant, par date, par catégorie, c'est trivial en SQL. Dans une base vectorielle dédiée, ce filtrage nécessite une configuration payload et une gestion séparée.

Les limites de pgvector à 1M de vecteurs

Les benchmarks publiés par pgvecto.rs et Qdrant montrent que pgvector avec l'index HNSW reste compétitif en latence jusqu'à environ 500 000 vecteurs sur du matériel standard. Au-delà, la latence P95 commence à dériver selon la configuration mémoire disponible.

Le problème clé de pgvector à grande échelle est la mémoire. L'index HNSW doit tenir en RAM pour des performances optimales. Pour 1 million de vecteurs de dimension 1536 en float32, l'index représente environ 6 à 10 Go selon les paramètres m et ef_construction. Si cet index ne tient pas en RAM, les performances chutent drastiquement.

-- Vérifier la taille de l'index
SELECT pg_size_pretty(pg_relation_size('documents_embedding_idx'));

-- Paramètre critique : work_mem pour les requêtes vectorielles
SET work_mem = '256MB';

L'autre limite est la parallélisation. Les requêtes vectorielles sur pgvector ne parallélisent pas aussi bien que Qdrant sur plusieurs CPU ou plusieurs nœuds.

Qdrant : ce que la spécialisation apporte

Performance brute

Qdrant est conçu pour la recherche vectorielle. Sur des corpus de 1M+ de vecteurs, la latence P95 est plus prévisible et les ressources nécessaires pour atteindre un SLA donné sont moindres qu'avec pgvector.

Les benchmarks ANN Benchmarks montrent que Qdrant sur la distance cosinus atteint un recall@10 de 0.98 avec une latence médiane de 2-3ms sur des corpus de 1M de vecteurs sur du matériel équivalent. pgvector avec HNSW bien configuré atteint des résultats comparables, mais est plus sensible aux paramètres et à la mémoire disponible.

Filtrage payload

Le point où Qdrant dépasse clairement pgvector pour les usages RAG complexes est le filtrage combiné vecteur + payload :

from qdrant_client import QdrantClient
from qdrant_client.models import Filter, FieldCondition, MatchValue, Range

results = client.search(
    collection_name="documents",
    query_vector=query_embedding,
    query_filter=Filter(
        must=[
            FieldCondition(key="tenant_id", match=MatchValue(value="tenant_123")),
            FieldCondition(key="created_at", range=Range(gte=1700000000)),
        ]
    ),
    limit=10
)

Qdrant indexe les payloads séparément des vecteurs et optimise les requêtes hybrides. Sur un RAG multi-tenant où chaque requête filtre par tenant et par période, ça fait une différence mesurable sur la latence à grande échelle.

Complexité opérationnelle

C'est là que Qdrant coûte. Un service supplémentaire à déployer, à superviser, à sauvegarder. La synchronisation entre Postgres (données transactionnelles) et Qdrant (vecteurs) est à implémenter et à maintenir. La cohérence entre les deux systèmes n'est pas garantie automatiquement.

On a eu un incident où un document supprimé dans Postgres restait présent dans Qdrant pendant plusieurs heures parce que le job de sync avait silencieusement échoué. Le RAG remontait des documents supprimés dans les résultats de recherche.

Notre grille de décision

Ce qu'on choisirait aujourd'hui

Pour un nouveau projet à 1M de documents avec une infrastructure qui part de zéro : Qdrant, avec Postgres pour les données transactionnelles et un job de sync explicite.

Pour un projet existant qui a déjà Postgres et qui passe de 100K à 1M de documents : rester sur pgvector d'abord, mesurer les performances réelles, et envisager Qdrant uniquement si les mesures montrent un problème.

La migration de pgvector vers Qdrant sur un système en production n'est pas triviale. Ce n'est pas une raison pour éviter Qdrant, mais c'est une raison pour ne pas migrer sans avoir des données concrètes qui justifient le coût opérationnel.

Ce qu'on ne recommande pas : choisir Qdrant parce que c'est une "vraie" base vectorielle dédiée, ou choisir pgvector parce que c'est plus simple à expliquer. Les deux outils sont sérieux. Le bon choix dépend de votre volume, de votre infrastructure existante, et de votre capacité à opérer un service supplémentaire.