Benchmark de bases de données vectorielles: 7 moteurs open source pour RAG

Nous avons évalué sept bases de données vectorielles open source auto-hébergées comme couche de récupération d’un pipeline RAG, chacune exécutée une par une 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, depuis la précision et la qualité de récupération jusqu’à la vitesse, la mémoire, la recherche filtrée et hybride, le coût de construction et le renouvellement en continu.

Vitesse à un seul 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, ce qui permet une comparaison équitable des chiffres de vitesse.

Sur un seul thread client, Redis sert 764 QPS sur MedRAG-50k avec un pic de RAM de 559 Mo, le débit le plus élevé et la mémoire la plus faible de l’ensemble. L’ordre en monothread est Redis 764, Qdrant 377, Milvus 342, Weaviate 341, pgvector 257, Chroma 197, LanceDB 70, soit un écart de 10x du premier au dernier. LanceDB est l’exception sur disque, troquant la RAM contre de 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 tombe de la troisième à la sixième place.

Pour le RAG, la latence de queue pilote 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 (aucun instantané RDB ni fichier append-only), donc ses chiffres de vitesse et de mémoire correspondent à une configuration volatile sans durabilité.

Débit sous concurrence

Le QPS monothread répond à la question de la vitesse d’une requête. La question de production est le débit sous de nombreux clients concurrents, et la réponse dépend de la manière dont le client est construit, pas de la base de données seule.

Un client en boucle fermée peut être piloté de deux façons, et toutes deux sont courantes dans les applications Python RAG. Un processus asynchrone ou threadé désérialise chaque résultat concurrent (gRPC/protobuf ou RESP) sur un unique GIL, de sorte que le client, et non le serveur, plafonne le débit. De nombreux processus workers (le motif gunicorn -w N) obtiennent chacun leur propre GIL, exposant bien davantage la capacité du serveur. Nous avons mesuré les deux sur une machine de 32 vCPU à un ef fixe de 128, et vérifié le rappel à chaque point.

À mesure que la concurrence des requêtes passe de 1 à 512 sur jusqu’à 32 processus workers, les courbes de débit se croisent. Redis démarre le plus haut à une requête et finit le plus bas, tandis que Weaviate grimpe du bas du classement jusqu’à un plateau de 8330 QPS à 512 requêtes, dépassant 7 114 au passage à 32. Sur un unique processus asynchrone, le classement suit plutôt l’efficacité de parsing du client Python, car le RESP de Redis est le plus léger à désérialiser et perd le moins face au GIL.

Le pic monoprocessus et le pic à 32 processus de chaque moteur sont les plafonds sur l’ensemble du balayage de 1 à 512, et non le débit à un nombre de requêtes donné.

Redis détient la latence de requête unique la plus basse de l’ensemble (environ 1.6 ms), et son cœur de recherche monothread 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 multithreadés) et pgvector (un backend Postgres indépendant par connexion) montent à l’échelle sur les 32 cœurs. pgvector a le pic monoprocessus le plus bas (536) et le deuxième pic à 32 processus le plus élevé (4832). Avec un budget p99 inférieur à 100ms, l’ordre multiprocessus est Weaviate 8290, pgvector 4828, Milvus 4725, Qdrant 1737, Redis 1642.

Le parsing gRPC plus lourd de Qdrant rend son chiffre colocalisé limité par le client plutôt que par une limite serveur, puisque le seul nombre de processus le fait passer de 455 QPS sur un processus à 1859 sur 32. Chroma et LanceDB ont été exclus de l’exécution multiprocessus. 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 de 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, sur les cinq moteurs en mémoire, va de 17.0 Go (Milvus) à 62.4 Go (Chroma), soit une plage de 3.7x, ou de 7.5 Go à 27.7 Go par million de vecteurs. Milvus reste le plus économe car il décharge l’index sur disque (de type DiskANN) tandis que les moteurs HNSW tout en RAM croissent le plus vite ; ainsi Milvus, le plus lourd à 50k (3 300 Mo), est le plus économe à 2.25M (17.0 Go), avec 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 au-dessus de 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 : ils constituent un niveau haut construit-et-servi, pas une empreinte de service uniquement, donc une nouvelle mesure en service seul est un raffinement ouvert.

Fraîcheur, écritures et suppressions sous renouvellement en continu

Les sept autres dimensions mesurent un corpus statique chargé en masse puis lu. Les bases de connaissances RAG réelles 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, de sorte que son débit est interne à cette section et non comparable aux chiffres de vitesse sur 32 cœurs. Les signaux de correction (vérifications de rappel et de tombstone) sont indépendants du matériel.

Fraîcheur (lecture après écriture). Au réglage de cohérence configuré pour chaque moteur, chacun est lecture-après-écriture. Un document nouvellement écrit est recherchable immédiatement, avec zéro écriture sur environ 150 non visible. La latence entre l’acquittement d’écriture et la visibilité en recherche est de 2 ms en 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 par 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 représentent une capacité de recherche du segment en croissance, une lecture-après-écriture valide côté utilisateur.

Écritures et lectures sous charge mixte. Avec un rédacteur visant 150 écritures/s et six lecteurs interrogeant pendant 60 secondes, le rappel en lecture est resté entre 0.96 et 1.00 pour chaque moteur, et aucun index ne s’est dégradé sous des écritures concurrentes. Le débit d’écriture ligne par ligne sépare les moteurs par 57x, et l’ordre est proche de l’inverse du classement de construction statique.

LanceDB paie une validation 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 face à une cible de 150/s sous lectures concurrentes ; les moteurs rapides sont donc plafonnés près de 150 plutôt que de montrer leur pic. Lisez ceci comme un comportement d’écriture en ligne haute fréquence ligne par ligne, pas comme 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 vivant et en réinsérant 20 % de nouveaux documents, la fuite de tombstones a été nulle pour chaque moteur. Un identifiant supprimé n’est jamais réapparu en recherche, et le Recall@10 est resté entre 0.97 et 1.00 après le cycle complet. La correction tient partout sous renouvellement. 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 en 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 le place au milieu du peloton.

Métriques expliquées

Rappel ANN@10 est la fraction des 10 vrais vecteurs voisins (selon un oracle kNN exact par force brute sur les mêmes embeddings que la base a indexés) que l’index approximatif a renvoyée. Il isole la base de données (type d’index, ef/nprobe, implémentation), pas l’embedding.

nDCG@10 est un score de 0 à 1 pondéré par la position indiquant si le bon document étiqueté par l’humain atterrit près du sommet 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, maintenue constante ici entre tous les moteurs.

Δ (pont delta) est le nDCG@10 de l’oracle moins le nDCG@10 de la base de données à un réglage de recherche donné. Il convertit l’erreur d’approximation de chaque moteur en la qualité de réponse que sa vitesse coûte, rapportable parce que nous disposons à la fois d’un oracle et d’étiquettes humaines.

Constats du benchmark des bases de données vectorielles

Les sept moteurs font jeu égal 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), soit un écart de 0.014. Le pont delta-vers-oracle va de 0.009 (LanceDB) à 0.023 (pgvector), donc l’approximation de la base de données coûte au maximum 0.023 point de nDCG de qualité de réponse.

Sous cet embedding, ce corpus, k=10 et ce point de fonctionnement de 0.95, le choix de la base de données déplace le nDCG@10 d’au plus 0.014, contre l’écart de 10x du débit monothread et l’écart de 3.7x de la 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, sur des corpus bien plus grands, ou avec des index quantifiés.

La fiabilité de la récupération varie davantage selon ce que demande une requête que selon la base de données qui y répond. Sur les 154 requêtes MedRAG à 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 recherches factuelles et l’existence de clause est présent de manière 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 rappel le plus défavorable Recall@10 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 regroupés). La séparation se situe dans le débit filtré.

La séparation se situe dans le débit. Chroma (11-19 QPS) et pgvector (10-56 QPS) tiennent le rappel à un débit filtré 20 à 40x inférieur à celui des autres. Milvus conserve le rappel le plus élevé dans le pire cas (0.984) avec 268 à 732 QPS sur toutes les sélectivités, tandis que Redis est le plus rapide à faible sélectivité (1 374 QPS à 1 %) avec un plancher de rappel plus bas (0.968). À une sélectivité de 1 à 5 %, un rappel de 1.00 est largement dû à la branche de balayage complet exact du planificateur de requêtes sous le seuil de balayage complet de chaque moteur, et non au HNSW filtrable, divulgué pour chaque moteur.

*Le rappel filtré de LanceDB a d’abord été mesuré à 0.24 sur des filtres regroupés, puis rétracté. Le balayage a fait varier ef, mais le paramètre de rappel de LanceDB est nprobes, il a donc tourné à une valeur par défaut d’environ 9 % des partitions. Re-mesuré avec des nprobes appropriés, le Recall@10 regroupé remonte de 0.24 à 0.76 (nprobes=128) puis à environ 1.00 (nprobes=256), à un QPS 3 à 5x plus bas. LanceDB tient le rappel filtré, lentement. Une nouvelle mesure à rappel apparié et sur le même hôte du débit filtré 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 par fusion de rang réciproque (RRF, k=60) augmente le nDCG@10 de 0.030 à 0.067 pour chaque moteur doté d’un bras de mots-clés. Sur MedRAG, les bras dense et BM25 sont presque de force égale individuellement (environ 0.80 chacun), donc le gain récupère les erreurs de chaque bras plutôt qu’un bras ne domine.

Les moteurs dotés d’un bras BM25 solide gagnent le plus, et pgvector et Weaviate gagnent moins, suivant leurs bras de mots-clés plus faibles (0.740 et 0.782). Aucun moteur ne voit son hybride tomber sous son bras dense une fois mesuré correctement.

Ce qui sépare les moteurs est la fusion native par rapport aux allers-retours côté client, de Milvus à 340 QPS natif à pgvector à 12 QPS côté client. Quatre moteurs fusionnent nativement (Qdrant, Milvus, Weaviate, LanceDB). Redis exécute BM25 et KNN natifs mais pas de fusion côté serveur dans cette version ; le client effectue donc 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 Postgres ts_rank (fréquence de terme avec normalisation de longueur, sans IDF), qui avec un balayage plein texte OR s’exécute à 12 QPS. Chroma auto-hébergé n’a aucune recherche de mots-clés classée (BM25 est une fonctionnalité de Chroma Cloud), donc aucune ligne hybride.

Le temps de construction de l’index s’étale 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 taux 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é à l’é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 standard à l’échelle du milliard ne comportent pas d’étiquettes de pertinence humaine, ils ne peuvent donc pas montrer ce qui se passe ensuite.

Le rappel ANN géométrique tient à l’é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 voisins. La qualité de réponse sémantique ne tient pas. Le nDCG@10 chute d’environ 0.81 à 50k à environ 0.56 à 2.25M pour chaque moteur, car le bon document 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 de l’oracle à 2.25M est 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 à un seul positif 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 la mise à l’échelle du corpus de 45x a effacé environ un tiers de la qualité de réponse (nDCG@10 de 0.81 à 0.56) tout en laissant chaque index ANN signaler un rappel quasi parfait, un effet qu’un benchmark purement géométrique manquerait.

Durabilité, haute disponibilité et sécurité par moteur

Vitesse, mémoire et 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 aussi 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, pgvector est le seul à offrir une récupération à un instant donné (via l’archivage WAL de 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 dans la version autonome mesurée ici. Aucun des sept ne chiffre les données sur disque nativement. Tous s’appuient sur un chiffrement de disque ou de volume au niveau de l’infrastructure.

Pour un RAG multi-locataire, où un filtre sert également de limite 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é la repoussent vers l’application. Un pré-filtre correct sous-retourne, un risque de complétude, plutôt que de fuiter les documents d’un autre locataire. Une fuite entre locataires nécessiterait un post-filtre buggé, ce qu’aucun de ces moteurs n’utilisait.

Comment fonctionne la recherche approximative des plus proches voisins

Une base de données vectorielles stocke un vecteur de grande dimension par document et, étant donné un vecteur de requête, renvoie 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 être servi.

Les index approximatifs de plus proches voisins (ANN) abandonnent une partie de la précision pour chercher dans une fraction des vecteurs stockés. La structure dominante dans ces moteurs est HNSW, un graphe de proximité en couches qui avance d’un point d’entrée grossier vers un voisinage dense, en visitant un nombre borné de candidats fixé par un paramètre de recherche (ef pour HNSW, nprobe pour IVF). Un ef plus grand visite plus de candidats, augmentant le rappel et abaissant le QPS. Un ef plus petit fait l’inverse.

Parce que ce paramètre échange le rappel contre la vitesse en continu, comparer deux moteurs à un réglage fixe est trompeur, puisque l’un peut dépenser plus de précision pour sa vitesse. La comparaison équitable balaie le paramètre, trace la courbe rappel contre QPS de chaque moteur, et les lit tous au même rappel. Ce point de rappel apparié (Recall@10 = 0.95 ici) est l’endroit où les chiffres de QPS, de latence et de mémoire de ce benchmark sont relevés.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Mé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 (aucun instantané RDB ni 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 filtrage et la construction, un conteneur à la fois, un conteneur neuf par construction d’index, et un client monothread colocalisé. La dimension de renouvellement en direct a été exécutée sur un CCX33 (8 vCPU, 32 Go).

Embedding. bge-m3, 1024 dimensions, cosinus sur float32 normalisés L2, k=10, graine 42, identique octet pour octet entre les moteurs. Les requêtes portent des étiquettes humaines à un seul positif (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 palier 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 Δ sont indépendants du matériel.

Statistiques. 100 exécutions ou plus par mesure, élagage des valeurs aberrantes IQR à 3.0x, chronométrage perf_counter_ns. Les pools de requêtes de 154 à 246 plafonnent le rapport de queue au 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 note les deux. La vérité terrain géométrique (Recall ANN@10 par rapport à l’oracle exact par force brute sur les mêmes vecteurs) demande si l’index a renvoyé les vrais vecteurs les plus proches, isolant la base de données. La vérité terrain sémantique (nDCG@10, MRR, Hit@k par rapport aux étiquettes humaines) demande si les documents renvoyés sont pertinents, ce qui est largement l’embedding, maintenue constante. Puisque l’embedding est gelé, classer les moteurs selon des 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.

Ancre 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 contradictoire avant le codage. La dimension hybride porte une réponse de référence BM25 indépendante (deux références s’accordent sur un nDCG d’environ 0.81), de sorte que tout moteur qui s’en écarte beaucoup signale un bug de harnais, pas un résultat. Cette garde a signalé trois erreurs de mesure de premier passage, toutes dans notre harnais (un artefact de chronométrage d’index asynchrone sur Weaviate, une mauvaise fonction de classement Postgres et un bug de SQL fusion qui faisait ignorer à HNSW son réglage 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 la même ancre (re-vérifications de rappel et de tombstones), donc aucun chiffre rapporté n’est rapide mais faux.

Signification statistique

Chaque chiffre rapporté est une estimation ponctuelle bootstrap sur 100 exécutions ou plus, avec un intervalle de confiance à 95 % issu 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 sont la preuve décisive. Quatre moteurs franchissent 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 qui est le sens de l’égalité. Les classements de vitesse et de mémoire se situent bien au-delà de cette incertitude, avec des écarts (10x de débit monothread, 3.7x de mémoire maximale) qui écrasent le bruit bootstrap.

Moteurs testés

Limites

Redis a été exécuté avec la persistance désactivée, donc une configuration avec fsync AOF modifierait sa latence d’écriture et son empreinte par rapport aux chiffres volatils rapportés ici.

Les étiquettes humaines sont à un seul positif (un seul 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 relèvent d’un benchmark séparé. Ce test isole la couche de récupération. Les étapes de re-ranking (cross-encodeur) et de génération de réponse par LLM d’un pipeline RAG sont hors périmètre. Les moteurs cloud gérés (Pinecone, Zilliz et d’autres) sont une phase ultérieure. La comparaison de durabilité et de sécurité est fondée sur la documentation, pas testée par chaos.

Pour aller plus loin

• Benchmark des modèles d’embedding
• Benchmark des re-rankers
• Calculateur de bases de données vectorielles
• Modèles d’embedding open source
• Modèles d’embedding multilingues
• Embeddings multimodaux
• Frameworks de RAG agentique

Citez ce benchmark

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}
}

Journal des modifications

3 mises à jour

1. 202617 Juil

   Faiss remplacé par LanceDB dans la liste des bases de données vectorielles comparées.

2. 27 Fév

   Ajout des mises à jour récentes à Milvus, Qdrant et Chroma.

3. 202514 Août

   Une nouvelle section, « Caractéristiques clés des bases de données vectorielles open source », a été ajoutée à l'article.

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA et scientifique des données chez AIMultiple. Il conçoit et exécute des benchmarks pratiques pour les systèmes d'IA et de LLM.

Voir le profil complet

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.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire