Milvus

Milvus est une base de données vectorielle open source conçue pour la recherche de similarité à grande échelle et haute performance, allant de millions de vecteurs sur une seule machine à des milliards de vecteurs répartis sur un cluster distribué. Créée par Zilliz et offerte à la LF AI & Data Foundation en 2020, elle est distribuée sous licence Apache 2.0 et développée par une équipe d'ingénieurs à temps plein, avec les contributions de plus de 200 développeurs open source dans le monde. Plus de 10 000 entreprises utilisent Milvus en production, dont NVIDIA, Salesforce, eBay, Airbnb et DoorDash. En avril 2026, la version stable actuelle est Milvus 2.6.x.

Sa fonctionnalité principale est la recherche des plus proches voisins approximatifs (ANN) sur des embeddings vectoriels à haute dimension, avec la prise en charge de plus de 11 types d'index, dont HNSW, IVF_FLAT, DiskANN, SCANN, et CAGRA accéléré par GPU via la bibliothèque cuVS de NVIDIA. Milvus 2.5 (décembre 2024) a ajouté la recherche en texte intégral native utilisant Sparse-BM25, permettant des requêtes hybrides vecteur-mot-clé dans un seul moteur sans déploiement séparé d'Elasticsearch. Milvus 2.6 (juin 2025) a introduit Woodpecker, un journal de transactions (WAL) cloud-native qui élimine la dépendance externe à Kafka/Pulsar, ainsi qu'un stockage hiérarchisé chaud/froid permettant de réduire les coûts de stockage jusqu'à 50 %. Zilliz exploite également Zilliz Cloud, un service Milvus entièrement géré avec une version gratuite, une tarification serverless à l'usage, et des clusters dédiés à partir de 99 $/mois.

Ce que fait réellement Milvus en avril 2026

Milvus exécute des recherches de similarité vectorielle sur des ensembles de données qui feraient planter d'autres outils. Le projet a connu deux refontes architecturales majeures : la ligne monolithique originale 1.x et l'architecture cloud-native entièrement désagrégée 2.x disponible aujourd'hui. La conception 2.x sépare le stockage, le calcul et la coordination en couches indépendantes, ce qui vous permet de faire évoluer les nœuds de requête séparément des nœuds d'ingestion de données en fonction de la nature réelle de la charge de travail.

La prise en charge des index est la plus vaste parmi les bases de données vectorielles open source. Au-delà de HNSW, vous disposez de variantes IVF pour les déploiements à mémoire limitée, de DiskANN pour les index à l'échelle du milliard sur disque, de SCANN pour les scénarios à haut rappel, et de quatre types d'index accélérés par GPU via NVIDIA cuVS. L'index GPU CAGRA offre un débit environ 10 fois supérieur sur les charges de travail de recherche par lots par rapport à HNSW sur CPU uniquement, à des niveaux de rappel comparables. Pour les équipes disposant d'une infrastructure GPU NVIDIA, il ne s'agit pas d'une amélioration marginale.

L'intégration de la recherche en texte intégral de Milvus 2.5 est l'ajout architectural le plus significatif des versions récentes. Avant la version 2.5, un modèle de production courant consistait à exécuter Milvus aux côtés d'Elasticsearch — Milvus pour la recherche sémantique, Elasticsearch pour la correspondance de mots-clés — et à fusionner les résultats dans la couche applicative. Milvus 2.5 a remplacé cela par Sparse-BM25 intégré, propulsé par l'indexation Tantivy. Le benchmark publié par Zilliz lors du lancement a montré que Milvus 2.5 renvoyait des résultats en 6 millisecondes contre 200 millisecondes pour Elasticsearch sur 1 million de vecteurs, soit une amélioration de 30x. Les équipes qui ont effectué la mise à jour ont éliminé un cluster entier de leur infrastructure.

Milvus 2.6 a abordé le problème de la dépendance à l'infrastructure sous un angle différent. Le nouveau système Woodpecker WAL élimine les exigences externes de Kafka ou Pulsar en persistant les données de journal directement vers le stockage objet (S3, GCS, MinIO). Woodpecker atteint un débit de 450 Mo/s en mode système de fichiers local, 3,5 fois plus rapide que Kafka, et 750 Mo/s vers S3, 5,8 fois plus rapide que Kafka. Cette simplification est particulièrement importante pour les équipes en auto-hébergement qui devaient auparavant exploiter et surveiller un cluster Kafka en plus d'etcd et du stockage objet.

« Les équipes s'appuient sur Milvus dans des environnements exigeants où les performances, la fiabilité et les coûts sont tous importants. À mesure que l'adoption augmente, nous continuerons d'écouter attentivement la communauté et de transformer cette confiance en une plateforme qui évolue pour la production en entreprise. » - James Luan, VP de l'ingénierie chez Zilliz, décembre 2025

Où se situe Milvus par rapport à Qdrant et Pinecone

Ces trois solutions couvrent l'essentiel de l'espace de décision pour les bases de données vectorielles en production, et elles diffèrent mécaniquement de manières qui comptent pour les choix de déploiement.

Qdrant est écrit en Rust et est livré sous forme de binaire unique sans aucune dépendance externe pour un déploiement autonome. Son index ANN principal est uniquement HNSW — un seul algorithme, bien optimisé, avec un riche filtrage de métadonnées intégré. Les benchmarks sur des vecteurs SQuAD à 384 dimensions montrent une latence de requête Qdrant à 94 ms contre 250 ms pour Milvus (Qdrant gagne sur la latence par requête), mais Milvus atteint environ 46 QPS contre 4,7 QPS pour Qdrant (Milvus gagne sur le débit d'environ 10x). Qdrant est le meilleur choix pour les charges de travail de moins de 100 millions de vecteurs où une latence à un chiffre en millisecondes compte plus que le débit global. Milvus prend l'avantage lorsque vos volumes d'ingestion, la concurrence des requêtes ou le nombre total de vecteurs nécessitent une mise à l'échelle horizontale — le clustering horizontal de Qdrant est plus simple que celui de Milvus mais n'est pas conçu pour les mêmes volumes de données. Qdrant ne prend pas non plus en charge l'accélération GPU. Milvus prend en charge NVIDIA CAGRA pour des gains de débit de 10x sur du matériel compatible.

Pinecone est entièrement propriétaire et à code source fermé, sans option d'auto-hébergement. Vous l'utilisez uniquement via leur service cloud géré. Pinecone abstrait entièrement la couche d'indexation — vous ne pouvez pas choisir le type d'index, ajuster les paramètres HNSW ou accéder aux composants internes de stockage. Pour les équipes sans mandat d'infrastructure, c'est une fonctionnalité : Pinecone passe en production en un après-midi. Pour les équipes qui ont besoin de portabilité des données, d'accès aux audits ou d'ajustement du compromis rappel-latence pour des charges de travail spécifiques, l'abstraction devient un plafond. La tarification diverge considérablement à grande échelle : le service géré de Pinecone coûte entre 700 et 1 200 $/mois pour 10 millions de vecteurs, tandis qu'une infrastructure Milvus auto-hébergée équivalente coûte généralement entre 500 et 2 000 $/mois selon le choix de l'instance, la différence résidant dans le contrôle opérationnel par rapport à la commodité du « zero-ops ». Les benchmarks de 2026 montrent Milvus à 8 ms de latence p95 avec environ 4 200 QPS contre Pinecone à 12 ms de latence p95 avec environ 2 800 QPS pour des charges de travail de requêtes comparables, donnant à Milvus un léger avantage de performance à grande échelle lorsque l'infrastructure est bien optimisée.

« Nous ne nous contentons pas de combiner deux approches de recherche — nous révolutionnons la recherche d'entreprise avec une solution 30 fois plus rapide tout en simplifiant considérablement l'infrastructure. » - Charles Xie, fondateur et PDG de Zilliz, 17 décembre 2024

À quoi ressemble la réalité du déploiement

Milvus est livré sous deux modes. Le mode autonome (Standalone) s'exécute sur Docker et convient au développement et aux charges de travail à petite échelle. Le mode Cluster est natif pour Kubernetes et constitue la voie recommandée pour la production. L'écart entre ces deux modes est significatif.

Un cluster Milvus en production nécessite, au minimum : un cluster Kubernetes, etcd pour le stockage des métadonnées, et un stockage objet (S3 ou MinIO). Avant Milvus 2.6, vous aviez également besoin de Kafka ou Pulsar pour le journal de transactions (WAL) — cette dépendance est désormais remplacée par Woodpecker, ce qui constitue une simplification significative. Le Milvus Operator (un opérateur Kubernetes maintenu par Zilliz) gère une grande partie de la structure de déploiement et de la gestion du cycle de vie. Utiliser Helm directement sans l'opérateur est possible mais fragile : les valeurs par défaut ne sont pas prêtes pour la production, et l'ajustement des limites de ressources, du nombre de réplicas et des classes de stockage avant qu'une charge de travail réelle ne survienne nécessite de l'expérience avec Kubernetes et les bases de données distribuées.

Pour les équipes sans cette expertise, Zilliz Cloud supprime entièrement la charge opérationnelle. Le service géré offre la même surface d'API Milvus avec une version gratuite (5 Go, 2,5 millions de vCUs/mois), un niveau Serverless à 4 $ par million de vCUs, et des clusters dédiés à partir de 99 $/mois. La plateforme Zilliz Cloud revendique un SLA de disponibilité de 99,95 % et fonctionne sur AWS, Azure et GCP. Les organisations migrant d'OpenSearch vers Zilliz Cloud ont signalé des réductions de coûts allant jusqu'à 8x tout en maintenant ou en améliorant les performances de recherche, selon l'annonce de la version de juin 2025 de Zilliz. La voie gérée est le choix réaliste pour les équipes qui souhaitent les capacités de Milvus sans l'investissement en infrastructure.

Pour qui Milvus est conçu

Milvus est le choix naturel lorsque votre charge de travail de recherche vectorielle est véritablement massive. Les équipes qui construisent des systèmes RAG devant effectuer des recherches sur des centaines de millions de fragments de documents, des moteurs de recommandation indexant des centaines de millions de produits ou d'éléments multimédias, ou des pipelines de recherche multimodale combinant des embeddings d'images et de textes à grande échelle — ce sont les scénarios pour lesquels Milvus a été conçu. Les index accélérés par GPU profitent particulièrement aux équipes exécutant du matériel NVIDIA dans leur pile d'inférence qui ont également besoin du débit de recherche le plus élevé possible.

Les équipes d'ingénierie des données ayant de l'expérience avec Kubernetes et une préférence pour le contrôle de l'infrastructure open source plutôt que pour la commodité gérée trouveront l'architecture de Milvus familière et sa flexibilité précieuse. La licence Apache 2.0 et la gouvernance de la LF AI & Data Foundation signifient qu'il n'y a pas d'enfermement propriétaire (vendor lock-in) sur la couche de données : vos embeddings vous appartiennent et sont portables d'un déploiement à l'autre.

L'écosystème d'intégration croissant renforce cela : Milvus fonctionne nativement avec LangChain, LlamaIndex, Haystack et LangGraph pour les pipelines d'agents et RAG, et se connecte aux plateformes de données via des connecteurs Apache Spark et Kafka pour les flux de travail d'ingestion à haut volume.

Ce que Milvus n'est pas

Milvus n'est pas le bon choix pour les équipes en phase de démarrage qui ont besoin d'une recherche vectorielle opérationnelle en un après-midi sans expertise Kubernetes. Chroma (Python embarqué, zéro infrastructure) ou Qdrant (binaire unique, API REST simple) vous permettent d'obtenir un prototype fonctionnel plus rapidement. La surcharge architecturale de Milvus ne devient un avantage que lorsque l'échelle, le débit ou les exigences de flexibilité des index le justifient.

Ce n'est pas une base de données relationnelle avec des capacités vectorielles greffées dessus. Les équipes exécutant principalement des requêtes structurées avec la recherche vectorielle comme filtre secondaire trouveront peut-être pgvector (extension Postgres) plus ergonomique — cela conserve toutes les données dans un seul système et évite d'avoir à exploiter une base de données distincte. Milvus brille lorsque la récupération vectorielle est l'opération principale, et non un filtre secondaire sur des résultats SQL.

Les équipes qui n'ont pas l'intention de gérer leur propre infrastructure et qui n'ont pas besoin des garanties de portabilité open source devraient évaluer Pinecone ou Zilliz Cloud directement. Il n'y a aucune raison d'absorber la complexité opérationnelle de Milvus si le seul avantage dont vous avez besoin est un point de terminaison de recherche vectorielle géré avec une authentification simple et une mise à l'échelle automatique.