Polydesk-logotype
Polydesk.ai — Header

Milvus

Milvus est une base de données vectorielle open source (licence Apache 2.0), distribuée et cloud-native, conçue pour gérer la recherche par similarité sur des dizaines de milliards de vecteurs avec un scaling horizontal natif sur Kubernetes.

Là où la plupart des vector stores commencent à montrer leurs limites au-delà de quelques millions de vecteurs, Milvus a été conçu dès le départ pour le scale massif. Son architecture distribuée sépare stockage, compute et coordination en composants indépendants, permettant de scaler chaque couche séparément selon le pattern de trafic. C’est la solution de choix pour les entreprises qui gèrent des milliards de vecteurs en production, comme Salesforce, PayPal, Shopee, Airbnb, eBay, NVIDIA et Roblox.

Milvus en bref
Catégorie
Vector Store / Base de données vectorielle distribuée
Licence
Apache 2.0
Développé par
Zilliz, projet gradué de la LF AI & Data Foundation (Linux Foundation)
Architecture
Distribuée, cloud-native, séparation stockage/compute sur Kubernetes
Cloud managé
Zilliz Cloud (fully managed, serverless)
Scale
Dizaines de milliards de vecteurs
GPU
Oui (NVIDIA CUDA via cuVS, algorithme CAGRA)
Alternatives
Pinecone, Qdrant, Weaviate, ChromaDB, pgvector
URL
milvus.io

Architecture distribuée

L’architecture distribuée est la caractéristique définitoire de Milvus. Elle sépare le système en quatre types de nœuds :

Coordinateurs (Coord) : orchestrent le load balancing et la gestion des données. Ils gèrent les métadonnées, le routage des requêtes et la coordination des index.

Nœuds de requête (Query Nodes) : exécutent les recherches vectorielles. Ils chargent les segments de données en mémoire et calculent les distances. Pour les workloads read-heavy, vous ajoutez des Query Nodes sans toucher au reste.

Nœuds de données (Data Nodes) : gèrent l’ingestion et la compaction des données. Pour les workloads write-heavy, vous scalez les Data Nodes indépendamment.

Nœuds d’indexation (Index Nodes) : construisent les index vectoriels en arrière-plan. L’indexation peut exploiter les GPU NVIDIA pour des gains de performance significatifs (algorithme CAGRA via la librairie cuVS).

Le stockage objet (S3, MinIO, GCS) sert de couche de persistance partagée. Cette architecture permet à Milvus de scaler chaque composant indépendamment selon les besoins : plus de Query Nodes pour le débit de lecture, plus de Data Nodes pour le débit d’écriture, le tout sans interruption de service.

Milvus 2.5+ et Woodpecker Milvus 2.6 introduit Woodpecker, un système de Write-Ahead Log (WAL) natif qui remplace la dépendance externe à Pulsar ou Kafka. Cela simplifie significativement le déploiement en réduisant le nombre de composants externes nécessaires pour un cluster Milvus en production.

Trois modes de déploiement

Milvus propose un spectre de déploiement qui couvre du prototypage au production enterprise :

Milvus Lite : une librairie Python embarquée, importable directement dans un notebook Jupyter ou un script. Pas de serveur, pas de Docker. Idéal pour l’apprentissage et le prototypage rapide. Installation : pip install pymilvus.

Milvus Standalone : un serveur mono-machine déployé via Docker. Convient pour les applications avec des millions de vecteurs sur un seul serveur. C’est le mode pour les petites productions et les développements.

Milvus Distributed : le mode cluster complet sur Kubernetes. Architecture cloud-native avec séparation stockage/compute, réplication, sharding et haute disponibilité. C’est le mode pour les milliards de vecteurs en production enterprise.

# Milvus Lite : prototypage en 3 lignes
from pymilvus import MilvusClient

client = MilvusClient("milvus_demo.db")  # Base locale, fichier unique
client.create_collection(
    collection_name="documents",
    dimension=1536
)

# Milvus Standalone ou Distributed
client = MilvusClient(uri="http://localhost:19530")
# Ou Zilliz Cloud
client = MilvusClient(
    uri="https://your-cluster.zillizcloud.com",
    token="YOUR_TOKEN"
)

Fonctionnalités principales

Large gamme d’algorithmes d’indexation

Milvus offre le plus large éventail d’index vectoriels du marché : HNSW (graphe navigable, le plus populaire), IVF_FLAT et IVF_SQ8 (index à fichiers inversés), IVF_PQ (quantization produit), FLAT (recherche exacte par force brute), DiskANN (index sur disque pour les volumes qui dépassent la RAM), et GPU_CAGRA (indexation accélérée par GPU). Ce choix permet d’optimiser finement le compromis recall/latence/coût selon le cas d’usage.

Recherche hybride et full-text

Milvus supporte nativement les vecteurs denses (embeddings classiques) et sparse (BM25, SPLADE, BGE-M3) dans la même collection. La recherche hybride combine les résultats des deux types de vecteurs via un reranking configurable. Depuis Milvus 2.5, le full-text search via BM25 est intégré nativement, sans passer par des sparse vectors pré-calculés. Vous définissez des fonctions BM25 au niveau de la collection, et Milvus gère le tokenizing et le scoring automatiquement.

Accélération GPU

Milvus est le seul vector store open source majeur avec un support GPU natif pour la construction d’index et la recherche. Via la librairie NVIDIA cuVS et l’algorithme CAGRA, la construction d’un index HNSW sur GPU est des ordres de grandeur plus rapide que sur CPU. Pour les organisations qui réindexent fréquemment de gros volumes (mise à jour quotidienne de millions de vecteurs), l’accélération GPU est un avantage significatif.

Multi-tenancy flexible

Milvus supporte l’isolation multi-tenant à quatre niveaux : database, collection, partition et partition key. Cette flexibilité permet de gérer de quelques centaines à des millions de tenants dans un seul cluster, avec des compromis différents entre isolation, performance et coût de gestion selon le niveau choisi.

Stockage hot/cold

Milvus implémente un stockage tiéré : les données fréquemment accédées (hot) restent en mémoire ou sur SSD pour des performances maximales. Les données moins accédées (cold) sont stockées sur du stockage objet (S3) à moindre coût. Ce mécanisme réduit significativement les coûts tout en maintenant des performances élevées pour les requêtes sur les données récentes.

Sécurité enterprise

Authentification utilisateur obligatoire, chiffrement TLS pour les communications, et RBAC (Role-Based Access Control) pour un contrôle d’accès granulaire. Ces fonctionnalités sont essentielles pour les déploiements enterprise où la protection des données sensibles est un prérequis.


Utilisation concrète

from pymilvus import MilvusClient, DataType

# Connexion
client = MilvusClient(uri="http://localhost:19530")

# Créer une collection avec schéma
schema = client.create_schema(auto_id=True, enable_dynamic_field=True)
schema.add_field("id", DataType.INT64, is_primary=True)
schema.add_field("text", DataType.VARCHAR, max_length=2000)
schema.add_field("embedding", DataType.FLOAT_VECTOR, dim=1536)
schema.add_field("category", DataType.VARCHAR, max_length=100)
schema.add_field("price", DataType.FLOAT)

# Configurer l'index
index_params = client.prepare_index_params()
index_params.add_index(
    field_name="embedding",
    index_type="HNSW",
    metric_type="COSINE",
    params={"M": 16, "efConstruction": 256}
)

client.create_collection(
    collection_name="products",
    schema=schema,
    index_params=index_params
)

# Insérer des données
data = [
    {"text": "Chaussures de randonnée imperméables", "embedding": [...], "category": "outdoor", "price": 129.99},
    {"text": "Sac à dos 40L ultraléger", "embedding": [...], "category": "outdoor", "price": 89.50},
]
client.insert(collection_name="products", data=data)

# Recherche vectorielle avec filtrage
results = client.search(
    collection_name="products",
    data=[query_embedding],  # Vecteur de requête
    anns_field="embedding",
    filter='category == "outdoor" and price < 150',
    limit=5,
    output_fields=["text", "category", "price"]
)

for hits in results:
    for hit in hits:
        print(f"{hit['entity']['text']} - {hit['entity']['price']}€ (score: {hit['distance']:.3f})")

Zilliz Cloud : le Milvus managé

Zilliz Cloud est la version fully managed de Milvus, développée par Zilliz (la société derrière Milvus). Chaque cluster Zilliz Cloud exécute Milvus sous le capot, avec en plus : le scaling automatique, la haute disponibilité, les backups, le monitoring, les mises à jour sans interruption et un moteur vectoriel propriétaire (Cardinal) qui offre des performances jusqu’à 3x supérieures aux benchmarks Milvus open source.

Zilliz Cloud est disponible sur AWS, GCP et Azure. Le pricing est basé sur le compute (CU : Compute Units) et le stockage, avec un free tier pour le prototypage. Le mode serverless élimine la gestion de cluster : vous créez une collection et Zilliz gère l’infrastructure.

Pour les organisations qui veulent la puissance de Milvus Distributed sans la complexité opérationnelle de Kubernetes, Zilliz Cloud est l’option naturelle.


Cas d’usage en production

RAG enterprise à grande échelle. Des organisations comme Salesforce et PayPal utilisent Milvus pour alimenter des systèmes RAG sur des corpus de milliards de documents internes. L’architecture distribuée garantit des performances stables même sous charge élevée avec des milliers de requêtes concurrentes.

Recherche d’images et multimodal. Les plateformes e-commerce (Shopee) et de contenu (Roblox) utilisent Milvus pour la recherche d’images similaires sur des catalogues de centaines de millions d’items. Le support des vecteurs multiples par objet permet de combiner embeddings texte et image dans la même collection.

Systèmes de recommandation. Les plateformes social/vidéo (BIGO, LINE) utilisent Milvus pour les recommandations temps réel basées sur la similarité des embeddings utilisateur et contenu. Le sharding et la réplication assurent le débit nécessaire pour servir des millions d’utilisateurs simultanés.

Détection de plagiat et deduplication. Des systèmes académiques et juridiques utilisent Milvus pour comparer des millions de documents et détecter les similarités sémantiques. Un témoignage indique que Milvus peut traiter des charges variables de 10 à 10 000+ documents par jour.


Forces et limites

Points forts

Scale massif prouvé. Milvus est déployé en production avec des dizaines de milliards de vecteurs chez des entreprises du Fortune 500. C’est la solution la plus éprouvée pour le scale extrême.

Architecture distribuée native. La séparation stockage/compute avec scaling indépendant de chaque composant est l’architecture la plus flexible pour s’adapter à des patterns de trafic variables.

GPU natif. L’accélération GPU pour la construction d’index et la recherche est un avantage unique pour les workloads intensifs en calcul.

Écosystème riche. Intégrations avec LangChain, LlamaIndex, Haystack, IBM Watsonx, OpenAI, et de nombreux outils de monitoring (Prometheus, Grafana, DataDog).

Communauté et gouvernance. Projet gradué de la Linux Foundation avec des contributeurs de Zilliz, ARM, NVIDIA, AMD, Intel, Meta, IBM, Salesforce, Alibaba et Microsoft. La gouvernance open source assure la pérennité du projet.

Limites

Complexité opérationnelle. Milvus Distributed nécessite Kubernetes, et historiquement des dépendances externes (etcd, Pulsar/Kafka, MinIO). La courbe d’apprentissage est significative pour les équipes sans expertise Kubernetes. Milvus 2.6 avec Woodpecker réduit ces dépendances, mais le déploiement reste plus complexe que Qdrant (un binaire Rust) ou Pinecone (SaaS).

Surdimensionné pour les petits volumes. Si vous avez quelques centaines de milliers de vecteurs, Milvus Distributed est excessif. Utilisez Milvus Lite ou Standalone, ou considérez des alternatives plus légères (pgvector, Qdrant, ChromaDB).

Latence sur petits volumes. L’overhead de l’architecture distribuée (coordination, routing) peut augmenter la latence pour les requêtes simples sur de petites collections, comparé à des solutions mono-nœud optimisées comme Qdrant.

Pas de vectorisation intégrée. Comme Qdrant, Milvus ne génère pas les embeddings pour vous. Vous devez calculer les vecteurs côté client.


Écosystème et intégrations

Milvus bénéficie de l’un des écosystèmes les plus larges parmi les vector stores open source :

Frameworks IA et RAG

LangChain, LlamaIndex, Haystack, Semantic Kernel, IBM Watsonx et les outils OpenAI supportent Milvus comme backend vectoriel. L’intégration se fait via le SDK Python pymilvus, qui fournit un client compatible avec Milvus Lite, Standalone, Distributed et Zilliz Cloud. Les pipelines RAG construits avec ces frameworks peuvent stocker et rechercher des millions de chunks de documents dans Milvus avec des performances prévisibles.

Monitoring et opérations

Milvus expose des métriques Prometheus natives pour le monitoring. L’intégration avec Grafana fournit des dashboards prêts à l’emploi pour surveiller le débit de requêtes, la latence, l’utilisation mémoire et l’état des segments. DataDog est également supporté pour les organisations qui centralisent leur observabilité sur cette plateforme. Le monitoring est critique pour Milvus Distributed, où plusieurs nœuds doivent être supervisés en permanence.

Intégrations de stockage

Milvus supporte plusieurs backends de stockage objet : Amazon S3, Google Cloud Storage, Azure Blob Storage, et MinIO (open source, S3-compatible) pour les déploiements on-premise. Le choix du backend de stockage est transparent pour les requêtes : les mêmes opérations fonctionnent quel que soit le stockage sous-jacent.

SDKs et interfaces

Milvus fournit des SDKs officiels pour Python, JavaScript/TypeScript, Java, Go et .NET (contribution Microsoft). En plus des SDKs, Milvus expose une API gRPC (haute performance) et une API REST (compatibilité large). L’interface graphique Attu (outil d’administration web) permet de visualiser les collections, les segments et les requêtes sans écrire de code.


Milvus vs alternatives

Critère Milvus Qdrant Pinecone Weaviate
Scale max Dizaines de milliards Milliards (distribué) Milliards (serverless) Millions à milliards
Architecture Distribuée native (K8s) Mono-nœud ou distribué Serverless managé Mono-nœud ou distribué
GPU Oui (NVIDIA CAGRA) Non Non Non
Index types 7+ (HNSW, IVF, PQ, DiskANN, GPU…) HNSW + quantization Propriétaire HNSW + flat
Complexité ops Élevée (K8s requis) Faible (binaire Rust) Zéro (SaaS) Moyenne
Cloud managé Zilliz Cloud Qdrant Cloud Natif (SaaS only) Weaviate Cloud
Cas idéal Milliards de vecteurs, enterprise Performance, coût-efficacité Zéro ops, production rapide AI-native, RAG intégré
Quand choisir Milvus Milvus est le bon choix quand : vous avez des centaines de millions à des milliards de vecteurs, vous avez besoin de scaling horizontal avec séparation stockage/compute, vous voulez exploiter les GPU NVIDIA pour l’indexation, ou vous êtes dans un contexte enterprise avec des exigences de haute disponibilité, RBAC et multi-tenancy avancée. Pour des volumes plus modestes (< 10 millions de vecteurs), Qdrant ou pgvector sont plus simples et souvent suffisants.

Verdict

Milvus est le vector store le plus puissant pour le scale massif en 2026. Son architecture distribuée, ses 7+ algorithmes d’indexation, son support GPU natif et sa communauté Linux Foundation en font la solution de référence pour les déploiements enterprise à milliards de vecteurs. Les benchmarks 2026 montrent des performances QPS 1,5x supérieures à Pinecone sur Milvus open source, et 3x supérieures sur Zilliz Cloud avec le moteur Cardinal.

Le compromis est clair : cette puissance vient avec une complexité opérationnelle réelle. Kubernetes est un prérequis pour le mode distribué, et la courbe d’apprentissage est la plus raide du marché des vector stores. Zilliz Cloud élimine cette complexité pour les équipes qui préfèrent un service managé.

La recommandation : si vos volumes dépassent 100 millions de vecteurs ou si vous anticipez cette croissance, Milvus (ou Zilliz Cloud) est le choix stratégique. Pour des volumes plus modestes, commencez par pgvector ou Qdrant, et migrez vers Milvus quand la scale l’exige. Conservez vos textes sources et embeddings dans un stockage que vous contrôlez (S3) pour faciliter la migration.


Questions fréquentes sur Milvus

Milvus est-il gratuit ?

Oui, Milvus est open source sous licence Apache 2.0, entièrement gratuit. Vous pouvez le déployer sur votre propre infrastructure sans frais de licence. Milvus Lite (embarqué Python) et Milvus Standalone (Docker) sont les options les plus simples pour démarrer. Zilliz Cloud (version managée) propose un free tier pour le prototypage, puis un pricing basé sur le compute et le stockage.

Milvus nécessite-t-il Kubernetes ?

Milvus Lite (embedded) et Milvus Standalone (Docker) fonctionnent sans Kubernetes. Seul Milvus Distributed (mode cluster pour les milliards de vecteurs) nécessite Kubernetes. Si votre équipe n’a pas d’expertise Kubernetes et que vos volumes ne justifient pas le mode distribué, utilisez Standalone (jusqu’à quelques millions de vecteurs) ou Zilliz Cloud (managé, pas de K8s à gérer).

Quelle est la différence entre Milvus et Zilliz Cloud ?

Zilliz Cloud est la version fully managed de Milvus, développée par la même société (Zilliz). Chaque cluster Zilliz exécute Milvus sous le capot. Zilliz ajoute le scaling automatique, la haute disponibilité, le monitoring, les backups et un moteur vectoriel propriétaire (Cardinal) qui offre des performances supérieures. Fonctionnellement, Milvus et Zilliz Cloud sont compatibles : le même code client fonctionne avec les deux.

Milvus ou Qdrant : lequel est le plus performant ?

Les deux sont performants mais optimisés pour des scénarios différents. Qdrant offre généralement de meilleures latences sur un seul nœud grâce à Rust (30-40ms p99). Milvus excelle en débit (QPS) sur des clusters distribués avec des milliards de vecteurs. Pour les volumes modérés (< 10M vecteurs) sur un seul serveur, Qdrant est souvent plus rapide et plus simple. Pour les volumes massifs nécessitant du scaling horizontal, Milvus est plus adapté.

Milvus supporte-t-il les GPU ?

Oui. Milvus est le seul vector store open source majeur avec un support GPU natif via NVIDIA CUDA et la librairie cuVS. L’algorithme GPU_CAGRA accélère significativement la construction d’index HNSW. C’est particulièrement utile pour les organisations qui reconstruisent régulièrement des index sur de gros volumes (réindexation quotidienne de centaines de millions de vecteurs). Le GPU n’est pas requis pour les requêtes : il accélère principalement la construction d’index.

Polydesk.ai — Footer