Comparatif bases vectorielles. Données, pas des impressions.

Chaque comparatif de bases vectorielles que vous avez lu déclare un gagnant, et ce gagnant est toujours celui qui a financé le benchmark. Nous avons conduit le nôtre sur notre propre infrastructure, avec nos propres données, contre notre propre vérité terrain. Mêmes 1,2 million de chunks, même modèle d'embeddings, mêmes 4 800 requêtes, testés sur pgvector, Pinecone, Qdrant et Weaviate. Nous avons mesuré ce qui compte réellement en production : la latence de queue, le recall réel, le coût total de possession et la charge opérationnelle que personne ne mentionne.

Version courte : aucun fournisseur n'a tout raflé. Qdrant gagne sur la latence. Pinecone gagne sur le recall. pgvector gagne sur le coût. Weaviate ne gagne rien de façon nette, mais propose un positionnement multi-modal que les autres n'ont pas. Les réponses intéressantes se trouvent dans les écarts entre ces titres.

Ce que nous avons réellement testé

Le jeu de données comprend 1,2 million de chunks issus d'un corpus d'entreprise mixte : documentation, transcriptions de support et contenu de base de connaissances interne. Chaque chunk a été embedé avec text-embedding-3-large à 3 072 dimensions, puis tronqué à 1 536 pour les solutions facturant par dimension. Chaque base a été chargée de façon identique. Aucun réglage d'index au-delà des valeurs par défaut recommandées par chaque fournisseur, sauf mention contraire pour pgvector.

Ensemble de requêtes : 4 800 requêtes tirées de journaux de retrieval réels, stratifiées par domaine (technique, procédural, factuel, ambigu). Les requêtes ont été exécutées à chaud, sans cache, sans optimisation de pool de connexions, depuis une seule instance EC2 m6i.2xlarge en us-east-1. Tous les services gérés se trouvaient dans la même région. pgvector tournait sur RDS db.r6g.2xlarge.

Le recall@10 a été mesuré par rapport à un ensemble de vérité terrain construit en effectuant une recherche exhaustive par force brute sur le corpus complet. C'est le chiffre honnête, pas le recall marketing des fournisseurs, généralement mesuré par rapport à leur propre approximation ANN.

Latence : p50 et p99, requêtes à froid

La latence est là où l'histoire se complique. Les chiffres p50 se regroupent plus étroitement qu'on ne s'y attend. Les services gérés ont convergé vers des performances médianes similaires. C'est le p99 qui les sépare. Qdrant affiche le p99 le plus bas, d'une marge significative. La queue de Weaviate est la plus longue, tirée vers le haut par les pauses de garbage collection de son environnement d'exécution JVM sur des ensembles de résultats volumineux.

Le p99 de pgvector nous a agréablement surpris par rapport aux attentes. L'index ivfflat sur RDS s'est comporté de façon plus constante que sa réputation ne le laisse entendre à cette échelle, bien que nous étions dans sa zone idéale à 1,2 million de vecteurs. À 5 millions et plus, l'histoire change probablement.

Recall@10 : le vrai chiffre

Le recall est la métrique la plus politiquement chargée dans tout comparatif de bases vectorielles, car chaque fournisseur publie une version qui lui est favorable. Le nôtre est mesuré par rapport à une recherche exacte par force brute : la véritable vérité terrain, pas une approximation d'approximation. Pinecone remporte cette catégorie. Son architecture serverless semble utiliser des paramètres HNSW ef plus élevés que les autres services gérés par défaut.

Le recall de pgvector était le plus sensible à la configuration de l'index. Avec ivfflat à lists=100 par défaut, le recall tombait à 0,87. Nous avons ajusté à lists=256 et probes=10, ce qui l'a remonté à 0,912. C'est tout de même le plancher du groupe. Si le recall est votre contrainte principale, pgvector exige plus d'attention de réglage que les alternatives gérées.

L'écart entre Pinecone et Qdrant (0,965 vs 0,951) est réel, mais pourrait se situer dans la marge de ce qui compte en aval. Dans notre cas d'usage, la différence de recall s'est traduite par environ 1,4 résultat pertinent supplémentaire par 100 requêtes : significatif pour certaines applications, pas pour d'autres.

Coût : $/1M lectures à volume de production

Les comparaisons de coût sont toujours approximatives, car les modèles de tarification diffèrent structurellement. Pinecone facture par unité de lecture, Qdrant Cloud facture la puissance de calcul, pgvector facture l'instance RDS. Nous avons modélisé 1 million de lectures par mois à notre distribution de requêtes observée et à la configuration minimale viable pour le servir sans latence de démarrage à froid.

L'avantage de coût de pgvector est réel, mais avec une nuance : il a un plancher fixe. À faible volume de lectures, vous payez l'instance RDS que vous l'utilisiez ou non. Le modèle serverless de Pinecone n'a pas de plancher. Vous payez uniquement ce que vous lisez. Le point de croisement où pgvector devient moins cher que Pinecone se situe autour de 400 000 lectures/mois. En dessous de ce seuil, le modèle serverless de Pinecone est en réalité moins cher en termes absolus.

À volume élevé de lectures (10 M+/mois), le coût effectif par lecture de pgvector continue de baisser tandis que les services gérés tendent à la hausse. Si vous opérez déjà Postgres et avez le trafic pour justifier le plancher, le calcul du coût total de possession devient convaincant.

Complexité opérationnelle : ce que personne ne dit

C'est la métrique qui n'apparaît jamais dans les benchmarks des fournisseurs et qui compte le plus en pratique. Nous avons évalué la complexité opérationnelle selon trois dimensions : la configuration initiale, la maintenance continue et l'observabilité. Les scores vont de 1 à 10, où un score plus élevé signifie une charge opérationnelle plus grande.

Le score d'observabilité de pgvector est son avantage le plus sous-estimé. Si votre équipe opère déjà Postgres, vous disposez de pg_stat_statements, d'EXPLAIN ANALYZE, des journaux de requêtes lentes standard et de toutes les intégrations de surveillance déjà câblées dans votre stack. Le transfert de connaissances opérationnelles est quasi nul.

La charge de maintenance de Pinecone est franchement la plus faible du groupe, et ce n'est pas serré. Mais son observabilité est opaque : vous obtenez ce que le tableau de bord affiche, et ce qu'il affiche ne suffit pas pour déboguer une régression de recall ou un pic de latence sans ouvrir un ticket de support.

Qui devrait utiliser quoi

La vérité inconfortable : si vous optimisez pour une seule métrique, la réponse est simple. Si vous optimisez simultanément sur la latence, le coût, le recall et la charge opérationnelle, Qdrant est ce qui ressemble le plus à un équilibriste à cette taille de jeu de données. Il ne remporte aucune catégorie de façon nette (sauf la latence), mais il n'a pas non plus de point faible sérieux. C'est ce qui compte en production.

Si vous souhaitez que nous évaluions quelle base est la bonne pour votre charge de retrieval, le formulaire de contact est le moyen le plus rapide. Nous offrons des révisions de 30 minutes pour les systèmes en production, gratuitement.