pgvector contre Qdrant : un benchmark sur 100 000 vecteurs de dimension 1536

Le débat « Postgres avec une extension ou base vectorielle dédiée » se résume le plus souvent à des affirmations péremptoires. Machine Learning Mastery propose de les remplacer par une mesure : pgvector et Qdrant tournent dans Docker sur la même machine, avec les mêmes 100 000 vecteurs de dimension 1536 (comme text-embedding-3-small d'OpenAI) et les mêmes paramètres d'index HNSW. Le résultat se lit à travers quatre métriques : la latence médiane p50, les queues de distribution p95 et p99, et le nombre de requêtes par seconde.

Un débat sans chiffres

L'histoire typique est la suivante. Un mardi, une équipe ajoute pgvector à un Postgres déjà en production. Les embeddings se trouvent à côté des données relationnelles, et une même requête filtre et cherche les éléments similaires. Six mois plus tard, un e-mail d'un éditeur arrive : il serait temps de migrer vers une « vraie » base vectorielle avant de heurter un plafond. Le message ne contient aucun benchmark, seulement de l'assurance.

pgvector est une extension open source pour Postgres, actuellement en version 0.8.6, compatible avec Postgres 13 et les versions ultérieures.

Elle ajoute un type natif vector, ainsi que la recherche exacte et approchée des plus proches voisins. Le vecteur est stocké dans la même table que l'enregistrement qu'il décrit, et même dans la même ligne si on le souhaite, et s'interroge en SQL classique. Il n'y a pas de service distinct, pas de seconde source de données à synchroniser, et pas de saut réseau entre la partie relationnelle et la partie vectorielle.

L'extension gère les vecteurs en simple et en demi-précision, les vecteurs binaires et les vecteurs creux, ainsi que cinq fonctions de distance : L2, produit scalaire, cosinus, L1 et Hamming.

Les cinq bases dédiées face auxquelles on compare Postgres

Une base vectorielle dédiée est un service à part, avec son propre processus et son propre stockage, conçu dès l'origine pour la recherche vectorielle. Le prix de ce choix est évident : il faut déployer un nouveau système, le superviser, le sauvegarder et le synchroniser avec la source de vérité. L'auteur passe en revue les cinq options les plus populaires :

• Pinecone : base cloud entièrement managée, sans configuration, pensée pour l'échelle entreprise avec un minimum d'exploitation.
• Qdrant : base hautes performances écrite en Rust, forte sur les requêtes rapides avec filtrage complexe sur des payloads JSON.
• Weaviate : système open source orienté IA, avec vectorisation intégrée et recherche hybride avec BM25.
• Milvus : base distribuée avec accélération GPU, destinée aux charges massives de plusieurs milliards de vecteurs.
• ChromaDB : base légère et embarquée pour le prototypage local et le développement en Python.

Pour la comparaison pratique, le choix s'est porté sur Qdrant : c'est le sujet du benchmark public contre pgvector le plus détaillé et le plus transparent sur le plan méthodologique, et l'article s'appuie sur ce travail.

Comment réaliser une mesure honnête

Postgres 17 avec l'extension est lancé à partir de l'image pgvector/pgvector:pg17, et Qdrant d'une seule commande docker run sur les ports 6333 et 6334. Les deux systèmes utilisent la dimension 1536 et la métrique cosinus. Le jeu de données est synthétique : 100 000 vecteurs issus d'une distribution normale avec un seed=42 fixe, normalisés à une longueur unitaire, comme le font les vrais modèles d'embeddings. Dans Qdrant, les données sont chargées par lots de 1000 points ; dans Postgres, via l'adaptateur pgvector-python.

Le choix décisif : les index sont identiques. Dans pgvector, l'index HNSW est créé avec m=16 et ef_construction=64 (ses valeurs par défaut), et Qdrant reçoit les mêmes valeurs via HnswConfigDiff. L'auteur écrit noir sur blanc que comparer deux systèmes avec des paramètres d'index différents produit deux résultats incomparables. Côté requêtes, hnsw.ef_search est lui aussi égal à 64, et la limite de résultats est de 10.

Les requêtes portent sur 200 nouveaux vecteurs, absents du jeu chargé. Sinon, un vecteur déjà présent dans l'index se retrouverait lui-même à une distance nulle, et la mesure perdrait tout sens. Le temps est mesuré avec perf_counter, les latences sont triées, et p95 et p99 sont lus aux positions correspondantes de la liste triée. Le QPS correspond au nombre de requêtes divisé par la durée totale du test.

Comment l'appliquer chez soi

Pour reproduire le test, il faut Docker avec Compose, Python 3.10+ et environ 8 Go de mémoire libre. Aucun compte cloud n'est nécessaire.

La logique de choix découle directement de l'architecture. Si les données vivent déjà dans Postgres et que la requête doit combiner un filtre sur des champs relationnels avec une recherche par similarité, pgvector évite d'ajouter un second système et la synchronisation qui va avec. Pour un filtrage rapide sur des champs JSON complexes, Qdrant convient. Pour des collections de plusieurs milliards de vecteurs, on envisage Milvus ; pour zéro exploitation, Pinecone ; pour la vectorisation intégrée et BM25, Weaviate.

Un conseil en dehors de la méthode : des vecteurs normaux aléatoires n'ont pas la structure en clusters des vrais embeddings, et le script ne mesure que les latences. Avant de décider d'une migration, relancez le même test sur vos propres embeddings et ajoutez une vérification du recall par rapport à une recherche exacte.