Benchmark de bases de données vectorielles: 7 moteurs open-source pour RAG
Nous avons benchmarké sept bases de données vectorielles open-source auto-hébergées en tant que couche de récupération d'un pipeline RAG, chacune exécutée une à la fois sur des embeddings bge-m3 identiques et des requêtes médicales et techniques réelles, de sorte que l'index de la base de données était la seule variable. La charge de travail couvrait MedRAG-50k, TechQA-28k, et un corpus de 2,25M vecteurs sur huit dimensions, de la précision et la qualité de récupération à la vitesse, la mémoire, la recherche filtrée et hybride, le coût de construction et le renouvellement en direct.
Vitesse en single-thread
Chaque moteur est évalué au même niveau de rappel, le point de fonctionnement partagé où son paramètre de recherche (soit ef soit nprobe) est ajusté jusqu'à atteindre un Recall@10 de 0,95, permettant une comparaison équitable des chiffres de vitesse.
Sur un seul thread client, Redis sert 764 QPS sur MedRAG-50k à 559 Mo de RAM maximale, le débit le plus élevé et la mémoire la plus basse de l'ensemble. L'ordre en single-thread est Redis 764, Qdrant 377, Milvus 342, Weaviate 341, pgvector 257, Chroma 197, LanceDB 70, un écart de 10x du premier au dernier. LanceDB est l'exception sur disque, troquant la RAM contre la latence avec un p95 proche de 22 ms. Redis reste le plus rapide et LanceDB le plus lent sur TechQA-28k (651 à 81) et à 2,25M (495 à 28), bien que le milieu se réorganise à grande échelle, où Milvus passe de la troisième à la sixième place.
Pour le RAG, la latence de queue détermine l'expérience utilisateur plus que le débit brut. La latence par requête, regroupée sur 100 exécutions de 154 requêtes à rappel apparié, suit l'ordre de débit.
Redis a été exécuté avec la persistance désactivée (pas de snapshot RDB ni de fichier append-only), donc ses chiffres de vitesse et de mémoire correspondent à une configuration volatile sans durabilité.
Débit sous concurrence
Le QPS en single-thread indique la vitesse d'une requête unique. La question en production est le débit avec de nombreux clients concurrents, et la réponse dépend de la façon dont le client est construit, pas seulement de la base de données.
Un client en boucle fermée peut être piloté de deux façons, toutes deux courantes dans les applications Python RAG. Un processus async ou threadé désérialise chaque résultat concurrent (gRPC/protobuf ou RESP) sur un seul GIL, donc c'est le client, pas le serveur, qui plafonne le débit. De nombreux processus worker (le pattern gunicorn -w N) obtiennent chacun leur propre GIL, exposant bien plus de la capacité du serveur. Nous avons mesuré les deux sur une machine de 32 vCPU à ef=128 fixe, et vérifié le rappel à chaque point.
À mesure que la concurrence des requêtes passe de 1 à 512 sur jusqu'à 32 processus worker, les courbes de débit se croisent. Redis commence le plus haut à une requête et termine le plus bas, tandis que Weaviate grimpe du bas du peloton jusqu'à un plateau de 8330 QPS à 512 requêtes, dépassant 7 114 au passage à 32. Sur un seul processus asynchrone, le classement suit plutôt l'efficacité d'analyse du client Python, puisque le RESP de Redis est le plus léger à désérialiser et perd le moins face au GIL.
Le pic en processus unique et le pic à 32 processus de chaque moteur sont les plafonds sur tout le balayage de 1 à 512, pas le débit à un nombre de requêtes donné.
Redis détient la latence par requête la plus basse de l'ensemble (environ 1,6 ms), et son cœur de recherche single-threadé sature autour de 1642 QPS à 32 requêtes concurrentes, puis anti-évolue au-delà (le pool de threads de requête WORKERS de RediSearch est désactivé par défaut). Weaviate et Milvus (serveurs multi-threadés) et pgvector (un backend Postgres indépendant par connexion) évoluent sur les 32 cœurs. pgvector a le pic en processus unique le plus bas (536) et le deuxième pic à 32 processus le plus élevé (4832). Avec un budget p99 inférieur à 100ms, l'ordre multi-processus est Weaviate 8290, pgvector 4828, Milvus 4725, Qdrant 1737, Redis 1642.
L'analyse gRPC plus lourde de Qdrant rend son nombre en co-localisation limité par le client plutôt que par le serveur, puisque le nombre de processus le fait à lui seul passer de 455 QPS sur un processus à 1859 sur 32. Chroma et LanceDB ont été exclus de l'exécution multi-processus. Chroma fige ef à la création de la collection et anti-évolue, avec un p99 de 13 secondes à 512 requêtes, et LanceDB est embarqué, donc le scénario client-réseau ne s'applique pas.
Empreinte mémoire
À 50k vecteurs, la RAM maximale va de 559 Mo (Redis, en RAM, persistance désactivée) à 3 300 Mo (Milvus), avec Weaviate à 1 201, LanceDB à 1 574, Chroma à 1 800, et pgvector à 2 024. Le classement change à 2,25M, où le compromis mémoire-versus-disque s'ouvre.
La RAM maximale à 2,25M, pour les cinq moteurs en mémoire, va de 17,0 Go (Milvus) à 62,4 Go (Chroma), un écart de 3,7x, soit 7,5 Go à 27,7 Go par million de vecteurs. Milvus reste le plus léger car il décharge l'index sur disque (style DiskANN) tandis que les moteurs HNSW tout en RAM grossissent le plus vite, donc Milvus, le plus lourd à 50k (3 300 Mo), est le plus léger à 2,25M (17,0 Go), et Chroma le plus lourd à 62,4 Go.
Les deux moteurs sur disque se situent en dehors de cette comparaison de RAM car leur empreinte est sur disque plutôt qu'en RAM. pgvector détient un index sur disque de 18,4 Go et LanceDB un de 12,0 Go à 2,25M, et leur RAM de service est un cache de pages sur cet index plutôt que l'ensemble de travail complet, ce qui n'a pas été mesuré. Une réserve s'applique aussi aux chiffres en mémoire. Il s'agit d'un pic de construction et de service, pas d'une empreinte de service seule, donc une nouvelle mesure en service seul est un raffinement à prévoir.
Fraîcheur, écritures et suppressions sous renouvellement en direct
Les sept autres dimensions mesurent un chargement en masse statique puis une lecture du corpus. Les vraies bases de connaissances RAG ajoutent, mettent à jour et suppriment des documents en continu pendant que l'index fusionne en arrière-plan. Cette charge de renouvellement a été exécutée sur MedRAG-50k sur une machine séparée de 8 vCPU, donc son débit est interne à cette section et non comparable aux chiffres de vitesse sur 32 cœurs. Les signaux de correction (rappel et vérifications de tombstone) sont indépendants du matériel.
Fraîcheur (lecture après écriture). Au réglage de cohérence avec lequel chaque moteur a été configuré, tous sont en lecture-après-écriture. Un document nouvellement écrit est immédiatement consultable, avec zéro sur environ 150 écritures non visibles. La latence entre l'acquittement d'écriture et la visibilité en recherche est de 2 ms p50 pour Redis, 4 ms pour Weaviate, 9 ms pour Qdrant, 12 ms pour Milvus, 14 ms pour pgvector, 31 ms pour LanceDB, et 41 ms pour Chroma. Milvus trouve la nouvelle ligne via un scan en cohérence forte du segment en croissance non encore scellé (le vecteur entre dans le graphe HNSW persistant plus tard), donc ses 12 ms correspondent à la consultabilité du segment en croissance, une lecture-après-écriture valide du point de vue utilisateur.
Écritures et lectures sous charge mixte. Avec un writer ciblant 150 écritures/s et six lecteurs interrogeant pendant 60 secondes, le rappel en lecture s'est maintenu entre 0,96 et 1,00 pour chaque moteur, et aucun index ne s'est dégradé sous les écritures concurrentes. Le débit d'écriture par ligne sépare les moteurs d'un facteur 57x, et l'ordre est proche de l'inverse du classement de construction statique.
LanceDB paie un commit copy-on-write par ligne et Chroma un ajout HTTP par ligne, c'est pourquoi les constructeurs statiques les plus rapides sont les plus lents sous renouvellement. Le débit d'écriture ici est le taux atteint par rapport à une cible de 150/s sous lectures concurrentes, donc les moteurs rapides sont plafonnés près de 150 plutôt que de montrer leur pic. Il faut lire ceci comme un comportement d'écriture en ligne par ligne unique à haute fréquence, pas une ingestion par lots, qui est le point de conception de ces moteurs et n'est pas testée ici.
Suppression et compaction. En supprimant un 20% aléatoire de l'ensemble actif et en réinsérant 20% de nouveaux documents, la fuite de tombstone a été nulle pour chaque moteur. Un identifiant supprimé n'est jamais réapparu dans la recherche, et le Recall@10 est resté entre 0,97 et 1,00 après le cycle complet. La correction est maintenue sous renouvellement partout. Le coût diffère selon le moteur. pgvector paie un VACUUM de 53 secondes et Milvus une compaction de 11 secondes, tandis que la réinsertion des moteurs à écriture lente domine (Chroma 276 s, LanceDB 1139 s pour environ 6 000 documents).
Weaviate a exécuté cette section avec 3 000 documents initiaux plutôt que 30 000 (son ingestion en masse synchrone est lente sur la petite machine), donc son QPS de lecture correspond à un corpus plus petit. À cette échelle, sa fraîcheur corrigée est d'environ 5 ms et son taux d'écriture d'environ 102/s, ce qui place les deux dans le milieu du peloton.
Métriques expliquées
ANN Recall@10 est la fraction des 10 vrais vecteurs les plus proches (selon un oracle kNN exact en force brute sur les mêmes embeddings que la base a indexés) que l'index approximatif a retournés. Cela isole la base de données (type d'index, ef/nprobe, implémentation), pas l'embedding.
nDCG@10 est un score pondéré par la position de 0 à 1 indiquant si le document correct étiqueté par un humain se trouve près du haut de la liste de résultats. Il mesure la pertinence de récupération de bout en bout, qui est largement une propriété du modèle d'embedding, maintenu constant ici pour chaque moteur.
Δ (delta bridge) est le nDCG@10 de l'oracle moins le nDCG@10 de la base de données à un paramètre de recherche donné. Il convertit l'erreur d'approximation de chaque moteur en qualité de réponse que sa vitesse coûte, rapportable parce que nous détenons à la fois un oracle et des étiquettes humaines.
Résultats du benchmark de bases de données vectorielles
Les sept moteurs sont à égalité sur la précision de récupération
À Recall@10 = 0,95 sur MedRAG-50k, le nDCG@10 se situe entre 0,803 (pgvector) et 0,817 (LanceDB), un écart de 0,014. Le delta bridge par rapport à l'oracle va de 0,009 (LanceDB) à 0,023 (pgvector), donc l'approximation de la base de données coûte au plus 0,023 points nDCG de qualité de réponse.
Avec cet embedding, ce corpus, k=10, et ce point de fonctionnement de 0,95, le choix de la base de données fait varier le nDCG@10 d'au plus 0,014, contre un écart de 10x en débit single-thread et un écart de 3,7x en mémoire maximale montrés ci-dessus. Le choix de l'index commence à faire bouger la qualité à Recall@10 = 0,99 ou plus, à un k plus grand, à des corpus bien plus grands, ou avec des index quantifiés.
La fiabilité de récupération varie davantage selon ce qu'une requête demande que selon quelle base de données y répond. Sur les 154 requêtes MedRAG avec l'oracle kNN exact, les recherches factuelles obtiennent 0,888 nDCG@10, les questions conditionnelles 0,836, les questions comparatives 0,779, et les questions d'existence de clause 0,763. L'écart de 0,125 entre les questions factuelles et d'existence de clause est présent de façon identique sur les sept moteurs.
Les filtres de métadonnées coûtent du débit, pas du rappel
Avec un prédicat de métadonnées appliqué, le Recall@10 dans le pire cas reste entre 0,968 (Redis) et 1,00 (Weaviate, pgvector, LanceDB) sur une grille de sélectivité (1/5/20/50%) et de corrélation des prédicats (dispersés et groupés). La séparation se fait sur le débit filtré.
La séparation se fait sur le débit. Chroma (11-19 QPS) et pgvector (10-56 QPS) maintiennent le rappel à un débit filtré 20 à 40x inférieur au reste. Milvus conserve le rappel le plus élevé en pire cas (0,984) avec 268 à 732 QPS selon la sélectivité, tandis que Redis est le plus rapide à faible sélectivité (1 374 QPS à 1%) avec un plancher de rappel plus bas (0,968). À 1-5% de sélectivité, un rappel de 1,00 est largement dû à la branche de scan complet exact du planificateur de requêtes en dessous du seuil de scan complet de chaque moteur, pas au HNSW filtrable, divulgué par moteur.
*Le rappel filtré de LanceDB a d'abord été mesuré à 0,24 sur les filtres groupés, puis rétracté. Le balayage a fait varier ef, mais le bouton de rappel de LanceDB est nprobes, donc il a été exécuté à une valeur par défaut d'environ 9% des partitions. Re-mesuré avec les nprobes appropriés, le Recall@10 groupé récupère de 0,24 à 0,76 (nprobes=128) jusqu'à environ 1,00 (nprobes=256), avec un QPS 3 à 5x inférieur. LanceDB maintient le rappel filtré, lentement. Une re-mesure du débit filtré apparié en rappel sur le même hôte est encore en attente, donc le QPS filtré de LanceDB n'est pas listé.
La recherche hybride ajoute jusqu'à 0,067 nDCG
Ajouter un bras de mots-clés BM25 standard et le fusionner avec le bras dense via la fusion de rang réciproque (RRF, k=60) augmente le nDCG@10 de 0,030 à 0,067 pour chaque moteur disposant d'un bras de mots-clés. Sur MedRAG, les bras dense et BM25 sont individuellement de force presque égale (environ 0,80 chacun), donc le gain récupère les erreurs de chaque bras plutôt qu'un bras ne domine.
Les moteurs avec un bras BM25 fort gagnent le plus, et pgvector et Weaviate gagnent moins, reflétant leurs bras de mots-clés plus faibles (0,740 et 0,782). L'hybride d'aucun moteur ne tombe en dessous de son bras dense une fois mesuré correctement.
Ce qui sépare les moteurs est la fusion native versus les allers-retours côté client, de Milvus à 340 QPS en natif à pgvector à 12 QPS côté client. Quatre moteurs fusionnent nativement (Qdrant, Milvus, Weaviate, LanceDB). Redis exécute BM25 et KNN nativement mais pas de fusion côté serveur dans cette version, donc le client effectue deux allers-retours et fusionne en Python. pgvector n'a pas d'API de fusion, fusionne côté client, et son bras de mots-clés est ts_rank Postgres (fréquence de terme avec normalisation de longueur, sans IDF), qui avec un scan full-text OR s'exécute à 12 QPS. Chroma auto-hébergé n'a pas du tout de recherche par mots-clés classée (BM25 est une fonctionnalité Chroma Cloud), donc il n'a pas de ligne hybride.
Le temps de construction de l'index s'étend sur 13x
À 50k vecteurs, la construction de l'index va de 7 secondes (LanceDB) et 11 à 13 (Weaviate, Milvus) jusqu'à 88 secondes (pgvector). À 2,25M, l'écart atteint 13x. LanceDB et Milvus terminent en 7 à 8 minutes, contre 44 minutes pour Redis et 92 pour pgvector. Normalisé au tarif de la machine, le coût de construction va de 0,04 € par 1M vecteurs (LanceDB) et 0,05 € (Milvus) à 0,58 € (pgvector). La construction est un coût unique, payé à nouveau seulement lorsque le corpus est réindexé.
Qualité de récupération à 2,25M vecteurs
Pour tester la qualité à grande échelle tout en conservant de vraies étiquettes humaines, nous avons construit un corpus de 2,25M vecteurs. Il combine les 50k documents MedRAG étiquetés avec 2,2M distracteurs pubmed, tous dans le même espace bge-m3, vérifiés en intégrité pour qu'aucun distracteur ne soit une cible mal étiquetée. Les jeux de données ANN standards à l'échelle du milliard ne portent pas d'étiquettes de pertinence humaine, donc ils ne peuvent pas montrer ce qui se passe ensuite.
Le rappel ANN géométrique se maintient à grande échelle. Chaque moteur atteint encore un Recall@10 supérieur à 0,973 à 2,25M (Qdrant et Milvus à 0,999), donc l'index trouve les vrais vecteurs les plus proches. La qualité sémantique des réponses ne tient pas. Le nDCG@10 chute d'environ 0,81 à 50k à environ 0,56 à 2,25M pour chaque moteur, parce que le document correct est noyé parmi 2,2M distracteurs.
L'effondrement n'est pas un effet de base de données. Il frappe l'oracle kNN exact de manière identique (le nDCG@10 oracle à 2,25M est de 0,572, et chaque moteur se situe à ce plafond autour de 0,55 à 0,57). Que la cause soit le plafond de l'embedding, l'ambiguïté du corpus, ou des étiquettes à positif unique qui manquent des quasi-doublons désormais pertinents n'est pas tranché ici. Séparer ces causes nécessite un ré-étiquetage humain des documents nouvellement classés en tête. Le fait rapportable est que multiplier la taille du corpus par 45x a effacé environ un tiers de la qualité des réponses (nDCG@10 de 0,81 à 0,56) tout en laissant chaque index ANN rapporter un rappel quasi parfait, un effet qu'un benchmark purement géométrique manquerait.
Durabilité, haute disponibilité et sécurité par moteur
La vitesse, la mémoire et le rappel sont les axes mesurés. Pour un déploiement RAG en production, les axes non mesurés (durabilité, haute disponibilité, contrôle d'accès) séparent également ces moteurs. Cet inventaire de capacités est fondé sur la documentation officielle de chaque moteur dans l'édition open-source benchmarkée. C'est un inventaire de capacités, pas un test de chaos. Le temps de basculement réel, la fenêtre de perte de données en reprise après crash, et l'isolation des locataires sous charge ne sont pas mesurés ici.
Parmi les sept, seul pgvector offre la récupération à un point dans le temps (via l'archivage WAL Postgres) et la sécurité au niveau des lignes. Qdrant, Milvus, et Weaviate livrent la réplication et le RBAC dans leurs versions open-source, avec la réserve que la haute disponibilité de Milvus réside dans le mode distribué plus lourd, pas la version standalone benchmarkée ici. Aucun des sept ne chiffre les données sur disque nativement. Tous dépendent du chiffrement du disque ou du volume au niveau de l'infrastructure.
Pour le RAG multi-locataire, où un filtre sert également de frontière de contrôle d'accès, Qdrant, Milvus, Weaviate, et pgvector peuvent appliquer l'isolation des locataires à l'intérieur de la base de données. Chroma et LanceDB embarqué repoussent cela à l'application. Un pré-filtre correct sous-retourne, un risque d'exhaustivité, plutôt que de fuiter les documents d'un autre locataire. Une fuite inter-locataire nécessiterait un post-filtre défectueux, qu'aucun de ces moteurs n'a utilisé.
Fonctionnement de la recherche approximative des plus proches voisins
Une base de données vectorielles stocke un vecteur de haute dimension par document et, étant donné un vecteur de requête, retourne les k plus proches selon une métrique de distance (ici le cosinus sur des vecteurs normalisés L2). La recherche exacte des plus proches voisins compare la requête à chaque vecteur stocké, ce qui est correct mais évolue linéairement avec la taille du corpus. À 50k vecteurs, c'est rapide. À des millions, c'est trop lent pour servir.
Les index approximatifs des plus proches voisins (ANN) sacrifient un peu de précision pour ne chercher qu'une fraction des vecteurs stockés. La structure dominante dans ces moteurs est HNSW, un graphe de proximité en couches qui descend d'un point d'entrée grossier vers un voisinage dense, en visitant un nombre borné de candidats défini par un bouton de recherche (ef pour HNSW, nprobe pour IVF). Un ef plus grand visite plus de candidats, augmentant le rappel et réduisant le QPS. Un ef plus petit fait l'inverse.
Parce que ce bouton échange le rappel contre la vitesse de manière continue, comparer deux moteurs à un paramètre fixe est trompeur, car l'un peut dépenser plus de précision pour sa vitesse. La comparaison équitable balaie le bouton, trace la courbe rappel-versus-QPS de chaque moteur, et les lit tous au même rappel. Ce point de rappel apparié (Recall@10 = 0,95 ici) est celui où les chiffres de QPS, latence et mémoire de ce benchmark sont pris.
Ajouter comme source préféréeMéthodologie du benchmark
Moteurs. Qdrant v1.18.1, Milvus v2.6.0, Weaviate 1.38.0, pgvector 0.8.x (Postgres 17), Chroma 1.5.0, Redis/RediSearch 8.2, et LanceDB 0.34.0, avec des images Docker épinglées. Redis a été exécuté avec la persistance désactivée (pas de snapshot RDB ni de fichier append-only).
Matériel. Un Hetzner CCX53 (32 vCPU dédiés, 128 Go de RAM, NVMe, nbg1) pour la précision, la vitesse, la mémoire, le filtré et la construction, un conteneur à la fois, un conteneur frais par construction d'index, et un client single-thread co-localisé. La dimension de renouvellement en direct a été exécutée sur un CCX33 (8 vCPU, 32 Go).
Embedding. bge-m3, 1024-dim, cosinus sur float32 normalisé L2, k=10, seed 42, identiques octet pour octet entre les moteurs. Les requêtes portent des étiquettes humaines à positif unique (target_doc_id).
Corpus. MedRAG-50k (154 requêtes) et TechQA-28k (151 requêtes) pour la qualité de récupération, et un corpus de 2,25M vecteurs (50k étiquetés plus 2,2M distracteurs) pour le niveau d'échelle. La dimension hybride a été ré-exécutée sur Docker local, donc son QPS est comparable entre les lignes hybrides, pas aux chiffres de la machine. Son nDCG et son Δ sont indépendants du matériel.
Statistiques. 100+ exécutions par mesure, élagage des valeurs aberrantes IQR à 3,0x, chronométrage perf_counter_ns. Les pools de requêtes de 154 à 246 plafonnent le reporting de queue à p95, occasionnellement p99. Le p99,9 est indéfini à ces effectifs.
Double vérité terrain. Une base de données vectorielles a deux vérités terrain indépendantes, et ce benchmark évalue les deux. La vérité terrain géométrique (ANN Recall@10 contre l'oracle exact en force brute sur les mêmes vecteurs) demande si l'index a retourné les vrais vecteurs les plus proches, isolant la base de données. La vérité terrain sémantique (nDCG@10, MRR, Hit@k contre des étiquettes humaines) demande si les documents retournés sont pertinents, ce qui est largement l'embedding, maintenu constant. Parce que l'embedding est gelé, classer les moteurs sur les scores sémantiques bruts classerait l'embedding. La puissance de la base de données se manifeste par la vitesse et la mémoire à rappel ANN apparié, et le pont Δ traduit sa perte d'approximation en qualité de réponse.
Ancrage de correction. Chaque recette par moteur (filtre et hybride) a été tirée de la documentation officielle à la version exacte et vérifiée de manière adversariale avant le codage. La dimension hybride porte une clé de réponse BM25 indépendante (deux références s'accordent à un nDCG d'environ 0,81), donc tout moteur s'en écartant fortement signale un bug de harnais, pas un résultat. Cette garde a signalé trois erreurs de mesure de première passe, toutes dans notre harnais (un artefact de chronométrage d'index asynchrone sur Weaviate, une mauvaise fonction de classement Postgres, et un bug de fusion SQL qui faisait que HNSW ignorait son paramètre ef), que nous avons corrigées en re-mesurant les sept moteurs dans un environnement cohérent, où les cinq moteurs déjà corrects ont reproduit leurs chiffres exactement. Les dimensions de concurrence et de renouvellement portent le même ancrage (revérifications de rappel et de tombstone), donc aucun chiffre rapporté n'est rapide-mais-faux.
Signification statistique
Chaque chiffre rapporté est une estimation ponctuelle par bootstrap sur 100+ exécutions, avec un intervalle de confiance à 95% à partir de 1 000 rééchantillonnages, et une différence compte comme réelle lorsque les deux intervalles ne se chevauchent pas.
Le gain hybride est le cas limite, donc ses intervalles constituent la preuve décisive. Quatre moteurs dépassent clairement zéro et deux non :
La précision de récupération est la même règle lue dans l'autre sens. Les nDCG@10 des sept moteurs tombent dans des intervalles qui se chevauchent sur un écart de 0,014, donc aucun ne gagne, ce que signifie l'égalité. Les classements de vitesse et de mémoire se situent bien en dehors de cette incertitude, avec des écarts (10x en débit single-thread, 3,7x en mémoire maximale) qui écrasent le bruit de bootstrap.
Moteurs testés
Limitations
Redis a été exécuté avec la persistance désactivée, donc une configuration avec fsync AOF changerait sa latence d'écriture et son empreinte par rapport aux chiffres volatils rapportés ici.
Les étiquettes humaines sont à positif unique (un document correct par requête), sans pertinence graduée ni accord inter-annotateurs, donc nDCG@10, MRR@10, et Hit@10 portent un signal quasi identique sur ces données. L'embedding est maintenu constant par conception. Les familles d'embeddings, les dimensions et le comportement multilingue font l'objet d'un benchmark séparé. Cette exécution isole la couche de récupération. Les étapes de reclassement (cross-encoder) et de génération de réponse par LLM d'un pipeline RAG sont hors périmètre. Les moteurs cloud managés (Pinecone, Zilliz, et autres) sont une phase ultérieure. La comparaison de durabilité et de sécurité est fondée sur la documentation, pas testée en chaos.
Conclusion
À rappel apparié, les sept moteurs sont à égalité sur la précision de récupération (écart de nDCG@10 0,014, delta-par-rapport-à-l'oracle 0,009 à 0,023) et se séparent sur la vitesse, la mémoire, le débit filtré, le support hybride, le coût de construction et le renouvellement en direct. La base de données à choisir se décide sur ces axes, pas sur la précision, avec cet embedding et ce point de fonctionnement.
Pour le RAG sensible à la latence ou à faible concurrence, Redis a enregistré la latence par requête la plus basse (environ 1,6 ms) avec la mémoire la plus basse (559 Mo), dans sa configuration sans persistance. Pour un débit soutenu avec un client multi-worker, Weaviate a atteint 8330 QPS, Milvus 5063, et pgvector 4832. Pour le RAG filtré ou multi-locataire, Milvus a maintenu un rappel de 0,984 jusqu'à 732 QPS filtré et Weaviate un rappel filtré de 1,00. Pour la récupération hybride, Qdrant a enregistré le plus grand gain (+0,067 nDCG, natif) et Milvus la fusion native la plus rapide (340 QPS). Pour une base de connaissances mise à jour en continu, Redis (144 écritures/s) et Milvus (149) ont absorbé le renouvellement par ligne unique tandis que LanceDB (2,6) et Chroma (12) ne l'ont pas fait. Pour un déploiement à grande échelle contraint en mémoire, Milvus a conservé l'empreinte la plus légère à 2,25M (17,0 Go, sur disque) et la construction à grande échelle la plus rapide (8 minutes). Pour les équipes déjà sur Postgres, pgvector sert le RAG dense à 257 QPS et maintient un rappel complet sous filtres de métadonnées, avec la construction la plus lente (88 s) et un hybride côté client à 12 QPS.
Le plafond de tout cela est l'embedding. Parce que la précision est limitée par l'embedding à ce point de fonctionnement, l'ordre mesuré changerait là où l'index recommence à compter, à une cible de rappel plus élevée (0,99+), un k plus grand, ou un corpus de 10M et plus où le compromis mémoire-versus-disque s'élargit. À 2,25M, un corpus assez grand pour enterrer la réponse a effacé la qualité de récupération pour tous les moteurs simultanément tandis que chaque index ANN rapportait encore un rappel quasi parfait.
Pour aller plus loin
- Benchmark de modèles d'embedding
- Benchmark de rerankers
- Calculateur de base de données vectorielles
- Modèles d'embedding open-source
- Modèles d'embedding multilingues
- Embeddings multimodaux
- Frameworks de RAG agentique
Citer cette recherche
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Benchmark de bases de données vectorielles: 7 moteurs open-source pour RAG}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/open-source-vector-databases}},
note = {AIMultiple. Consulté le 17 Juillet 2026}
}
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.