MinIO n'accepte plus les modifications de la communauté : Évaluation de RustFS en tant que backend de stockage d'objets compatible S3 viable pour Milvus

Ce billet a été rédigé par Min Yin, l'un des contributeurs communautaires les plus actifs de Milvus, et est publié ici avec sa permission.

MinIO est un système de stockage d'objets open-source, très performant et compatible S3, largement utilisé dans l'IA/ML, l'analytique et d'autres charges de travail à forte intensité de données. Pour de nombreux déploiements Milvus, il a également été le choix par défaut pour le stockage d'objets. Cependant, l'équipe MinIO a récemment mis à jour son README GitHub pour indiquer que ce projet n'accepte plus de nouvelles modifications.

En fait, au cours des dernières années, MinIO s'est progressivement orienté vers des offres commerciales, a resserré son modèle de licence et de distribution et a réduit le développement actif dans le référentiel communautaire. Le passage du projet open-source en mode maintenance est l'aboutissement naturel de cette transition plus large.

Pour les utilisateurs de Milvus qui s'appuient sur MinIO par défaut, il est difficile d'ignorer ce changement. Le stockage d'objets est au cœur de la couche de persistance de Milvus, et sa fiabilité au fil du temps dépend non seulement de ce qui fonctionne aujourd'hui, mais aussi du fait que le système continue d'évoluer en même temps que les charges de travail qu'il prend en charge.

Dans ce contexte, cet article explore RustFS comme une alternative potentielle. RustFS est un système de stockage d'objets compatible S3, basé sur Rust, qui met l'accent sur la sécurité de la mémoire et la conception de systèmes modernes. Il est encore expérimental et cette discussion n'est pas une recommandation de production.

L'architecture Milvus et l'emplacement du composant de stockage d'objets

Milvus 2.6 adopte une architecture stockage-informatique entièrement découplée. Dans ce modèle, la couche de stockage est composée de trois éléments indépendants, chacun jouant un rôle distinct.

Etcd stocke les métadonnées, Pulsar ou Kafka gère les journaux en continu et le stockage d'objets - typiquement MinIO ou un service compatible S3 - fournit une persistance durable pour les données vectorielles et les fichiers d'index. Le stockage et le calcul étant séparés, Milvus peut faire évoluer les nœuds de calcul de manière indépendante tout en s'appuyant sur un backend de stockage partagé et fiable.

Le rôle du stockage d'objets dans Milvus

Le stockage d'objets est la couche de stockage durable de Milvus. Les données vectorielles brutes sont conservées sous forme de binlogs et les structures d'index telles que HNSW et IVF_FLAT y sont également stockées.

Cette conception rend les nœuds de calcul apatrides. Les nœuds de requête ne stockent pas les données localement, mais chargent à la demande des segments et des index à partir du stockage d'objets. Par conséquent, les nœuds peuvent évoluer librement à la hausse ou à la baisse, se rétablir rapidement en cas de défaillance et prendre en charge l'équilibrage dynamique de la charge dans le cluster sans rééquilibrage des données au niveau de la couche de stockage.

my-milvus-bucket/
├── files/                          # rootPath (default)
│   ├── insert_log/                 # insert binlogs
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Field_ID}/
│   │                   └── {Log_ID}     # Per-field binlog files
│   │
│   ├── delta_log/                  # Delete binlogs
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Log_ID}        
│   │
│   ├── stats_log/                  # Statistical data (e.g., Bloom filters)
│   │   └── {Collection_ID}/
│   │       └── {Partition_ID}/
│   │           └── {Segment_ID}/
│   │               └── {Field_ID}/
│   │                   └── {Log_ID}
│   │
│   └── index_files/                # Index files
│       └── {Build_ID}_{Index_Version}_{Segment_ID}_{Field_ID}/
│           ├── index_file_0
│           ├── index_file_1
│           └── ...

Pourquoi Milvus utilise l'API S3

Plutôt que de définir un protocole de stockage personnalisé, Milvus utilise l'API S3 comme interface de stockage d'objets. S3 est devenu le standard de facto pour le stockage d'objets : les principaux fournisseurs de cloud tels que AWS S3, Alibaba Cloud OSS et Tencent Cloud COS le prennent en charge de manière native, tandis que les systèmes open-source tels que MinIO, Ceph RGW, SeaweedFS et RustFS sont entièrement compatibles.

En standardisant l'API S3, Milvus peut s'appuyer sur des SDK Go matures et bien testés au lieu de maintenir des intégrations distinctes pour chaque backend de stockage. Cette abstraction offre également aux utilisateurs une grande souplesse de déploiement : MinIO pour le développement local, stockage d'objets dans le nuage en production, ou Ceph et RustFS pour les environnements privés. Tant qu'un point d'extrémité compatible S3 est disponible, Milvus n'a pas besoin de savoir - ou de se soucier - du système de stockage utilisé en dessous.

# Milvus configuration file milvus.yaml
minio:
 address: localhost
 port: 9000
 accessKeyID: minioadmin
 secretAccessKey: minioadmin
 useSSL: false
 bucketName: milvus-bucket

Évaluation de RustFS en tant que backend de stockage d'objets compatible S3 pour Milvus

Présentation du projet

RustFS est un système de stockage d'objets distribué écrit en Rust. Il est actuellement en phase alpha (version 1.0.0-alpha.68) et vise à combiner la simplicité opérationnelle de MinIO avec les forces de Rust en matière de sécurité mémoire et de performance. Plus de détails sont disponibles sur GitHub.

RustFS est toujours en développement actif, et son mode distribué n'a pas encore été officiellement publié. Par conséquent, RustFS n'est pas recommandé pour la production ou les charges de travail critiques à ce stade.

Conception de l'architecture

RustFS suit une conception similaire à celle de MinIO. Un serveur HTTP expose une API compatible S3, tandis qu'un gestionnaire d'objets gère les métadonnées des objets et qu'un moteur de stockage est responsable de la gestion des blocs de données. Au niveau de la couche de stockage, RustFS s'appuie sur des systèmes de fichiers standard tels que XFS ou ext4.

Pour son mode distribué prévu, RustFS a l'intention d'utiliser etcd pour la coordination des métadonnées, avec plusieurs nœuds RustFS formant un cluster. Cette conception s'aligne étroitement sur les architectures courantes de stockage d'objets, rendant RustFS familier aux utilisateurs ayant l'expérience de MinIO.

Compatibilité avec Milvus

Avant d'envisager RustFS comme solution alternative de stockage d'objets, il est nécessaire d'évaluer s'il répond aux exigences de base de Milvus en matière de stockage.

Exigences de Milvus	API S3	Prise en charge de RustFS
Persistance des données vectorielles	PutObject, GetObject	✅ Entièrement pris en charge
Gestion des fichiers d'index	ListObjects, DeleteObject	✅ Entièrement pris en charge
Opérations de fusion de segments	Chargement en plusieurs parties	Entièrement pris en charge
Garanties de cohérence	Forte lecture après écriture	Cohérence forte (nœud unique)

Sur la base de cette évaluation, l'implémentation actuelle de l'API S3 de RustFS satisfait aux exigences fonctionnelles de base de Milvus. Elle est donc adaptée aux tests pratiques dans les environnements de non-production.

Travaux pratiques : remplacement de MinIO par RustFS dans Milvus

L'objectif de cet exercice est de remplacer le service de stockage d'objets MinIO par défaut et de déployer Milvus 2.6.7 en utilisant RustFS comme backend de stockage d'objets.

Conditions préalables

1. Docker et Docker Compose sont installés (version ≥ 20.10), et le système peut tirer des images et exécuter des conteneurs normalement.

2. Un répertoire local est disponible pour le stockage des données d'objets, tel que /volume/data/ (ou un chemin personnalisé).

3. Le port hôte 9000 est ouvert pour l'accès externe, ou un port alternatif est configuré en conséquence.

4. Le conteneur RustFS fonctionne en tant qu'utilisateur non root (rustfs). Assurez-vous que le répertoire de données de l'hôte appartient à l'UID 10001.

Étape 1 : Créer le répertoire de données et définir les permissions

# Create the project directory
mkdir -p milvus-rustfs && cd milvus-rustfs
# Create the data directory
mkdir -p volumes/{rustfs, etcd, milvus}
# Update permissions for the RustFS directory
sudo chown -R 10001:10001 volumes/rustfs

Télécharger le fichier officiel Docker Compose

wget https://github.com/milvus-io/milvus/releases/download/v2.6.7/milvus-standalone-docker-compose.yml -O docker-compose.yml

Étape 2 : Modifier le service de stockage d'objets

Définir le service RustFS

Note : Assurez-vous que la clé d'accès et la clé secrète correspondent aux informations d'identification configurées dans le service Milvus.

rustfs:
 container_name: milvus-rustfs
 image: registry.cn-hangzhou.aliyuncs.com/rustfs/rustfs: latest
 environment:
 RUSTFS_ACCESS_KEY: minioadmin
 RUSTFS_SECRET_KEY: minioadmin
 RUSTFS_CONSOLE_ENABLE: “true”
 RUSTFS_REGION: us-east-1
 # RUSTFS_SERVER_DOMAINS: localhost# Optional; not required for local deployments
 ports:
 - “9001:9001”
 - “9000:9000”
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/rustfs:/data
 command: >
 --address :9000
 --console-enable
 /data
 healthcheck:
 test: [“CMD”, “curl”, “-f”, “http://localhost:9000/health"]
 interval: 30s
 timeout: 20s
 retries: 3

Configuration complète

Remarque : la configuration du stockage de Milvus suppose actuellement des valeurs par défaut de type MinIO et n'autorise pas encore les valeurs personnalisées de clé d'accès ou de clé secrète. Lorsque RustFS est utilisé en remplacement, il doit utiliser les mêmes informations d'identification par défaut que celles attendues par Milvus.

version: ‘3.5’
services:
 etcd:
 container_name: milvus-etcd
 image: registry.cn-hangzhou.aliyuncs.com/etcd/etcd: v3.5.25
 environment:
 - ETCD_AUTO_COMPACTION_MODE=revision
 - ETCD_AUTO_COMPACTION_RETENTION=1000
 - ETCD_QUOTA_BACKEND_BYTES=4294967296
 - ETCD_SNAPSHOT_COUNT=50000
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd
 command: etcd -advertise-client-urls=http://etcd:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd
 healthcheck:
 test: [“CMD”, “etcdctl”, “endpoint”, “health”]
 interval: 30s
 timeout: 20s
 retries: 3
 rustfs:
 container_name: milvus-rustfs
 image: registry.cn-hangzhou.aliyuncs.com/rustfs/rustfs: latest
 environment:
 RUSTFS_ACCESS_KEY: minioadmin
 RUSTFS_SECRET_KEY: minioadmin
 RUSTFS_CONSOLE_ENABLE: “true”
 RUSTFS_REGION: us-east-1
 # RUSTFS_SERVER_DOMAINS: localhost# Optional; not required for local deployments
 ports:
 - “9001:9001”
 - “9000:9000”
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/rustfs:/data
 command: >
 --address :9000
 --console-enable
 /data
 healthcheck:
 test: [“CMD”, “curl”, “-f”, “http://localhost:9000/health"]
 interval: 30s
 timeout: 20s
 retries: 3
 standalone:
 container_name: milvus-standalone
 image: registry.cn-hangzhou.aliyuncs.com/milvus/milvus: v2.6.7
 command: [”milvus“, ”run“, ”standalone“]
 security_opt:
 - seccomp: unconfined
 environment:
 MINIO_REGION: us-east-1
 ETCD_ENDPOINTS: etcd:2379
 MINIO_ADDRESS: rustfs:9000
 MINIO_ACCESS_KEY: minioadmin
 MINIO_SECRET_KEY: minioadmin
 MINIO_USE_SSL: ”false“
 MQ_TYPE: rocksmq
 volumes:
 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus
 healthcheck:
 test: [”CMD“, ”curl“, ”-f“, ”http://localhost:9091/healthz"]
 interval: 30s
 start_period: 90s
 timeout: 20s
 retries: 3
 ports:
 - “19530:19530”
 - “9091:9091”
 depends_on:
 - “etcd”
 - “rustfs”
networks:
 default:
 name: milvus

Démarrer les services

docker-compose -f docker-compose.yaml up -d

Vérifier l'état des services

docker-compose ps -a

Accéder à l'interface Web de RustFS

Ouvrir l'interface Web de RustFS dans votre navigateur : http://localhost:9001

Se connecter en utilisant les informations d'identification par défaut : le nom d'utilisateur et le mot de passe sont tous deux minioadmin.

Tester le service Milvus

from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType
# connect to Milvus
connections.connect(
 alias="default",
 host='localhost',
 port='19530'
)
print("✓ Successfully connected to Milvus!")
# create test collection
fields = [
 FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
 FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=128)
]
schema = CollectionSchema(fields=fields, description="test collection")
collection = Collection(name="test_collection", schema=schema)
print("✓ Test collection created!")
print("✓ RustFS verified as the S3 storage backend!")
### Step 3: Storage Performance Testing (Experimental)
Test Design
Two Milvus deployments were set up on identical hardware (16 cores / 32 GB memory / NVMe SSD), using RustFS and MinIO respectively as the object storage backend. The test dataset consisted of 1,000,000 vectors with 768 dimensions, using an HNSW index with parameters M = 16 and efConstruction = 200. Data was inserted in batches of 5,000.
The following metrics were evaluated: Insert throughput, Index build time, Cold and warm load time, Search latency, Storage footprint.
Test Code
Note: Only the core parts of the test code are shown below.

def milvus_load_bench(dim=768, rows=1_000_000, batch=5000) : collection = Collection(...) # Insert test t0 = time.perf_counter() for i in range(0, rows, batch) : collection.insert([rng.random((batch, dim), dtype=np.float32).tolist()] insert_time = time.perf_counter() - t0 # Index build collection.flush() collection.create_index(field_name="embedding", index_params={"index_type" : "HNSW", ...}) # Load test (cold start + two warm starts) collection.release() load_times = [] for i in range(3) : if i > 0 : collection.release() ; time.sleep(2) collection.load() load_times.append(...) # Test de requête search_times = [] for _ in range(3) : collection.search(queries, limit=10, ...)

**Test Command**

python bench.py milvus-load-bench --dim 768 --rows 1000000 --batch 5000
-index-type HNSW --repeat-load 3 --release-before-load --do-search --drop-after

**Performance Results**

RustFS

Faster writes (+57%), lower storage usage (–57%), and faster warm loads (+67%), making it suitable for write-heavy, cost-sensitive workloads.
Much slower queries (7.96 ms vs. 1.85 ms, ~+330% latency) with noticeable variance (up to 17.14 ms), and 43% slower index builds. Not suitable for query-intensive applications.

MinIO

Excellent query performance (1.85 ms average latency), mature small-file and random I/O optimizations, and a well-established ecosystem.


Metric
RustFS
MinIO
Difference


Insert Throughput
4,472 rows/s
2,845 rows/s
0.57
Index Build Time
803 s
562 s
-43%
Load (Cold Start)
22.7 s
18.3 s
-24%
Load (Warm Start)
0.009 s
0.027 s
0.67
Search Latency
7.96 ms
1.85 ms
-330%
Storage Usage
7.8 GB
18.0 GB
0.57


RustFS significantly outperforms MinIO in write performance and storage efficiency, with both showing roughly 57% improvement. This demonstrates the system-level advantages of the Rust ecosystem. However, the 330% gap in query latency limits RustFS’s suitability for query-intensive workloads.
For production environments, cloud-managed object storage services like AWS S3 are recommended first, as they are mature, stable, and require no operational effort. Self-hosted solutions are better suited to specific scenarios: RustFS for cost-sensitive or write-intensive workloads, MinIO for query-intensive use cases, and Ceph for data sovereignty. With further optimization in random read performance, RustFS has the potential to become a strong self-hosted option.
Conclusion
      
    
MinIO’s decision to stop accepting new community contributions is disappointing for many developers, but it won’t disrupt Milvus users. Milvus depends on the S3 API—not any specific vendor implementation—so swapping storage backends is straightforward. This S3-compatibility layer is intentional: it ensures Milvus stays flexible, portable, and decoupled from vendor lock-in.
For production deployments, cloud-managed services such as AWS S3 and Alibaba Cloud OSS remain the most reliable options. They’re mature, highly available, and drastically reduce the operational load compared to running your own object storage. Self-hosted systems like MinIO or Ceph still make sense in cost-sensitive environments or where data sovereignty is non-negotiable, but they require significantly more engineering overhead to operate safely at scale.
RustFS is interesting—Apache 2.0-licensed, Rust-based, and community-driven—but it’s still early. The performance gap is noticeable, and the distributed mode hasn’t shipped yet. It’s not production-ready today, but it’s a project worth watching as it matures.
If you’re comparing object storage options for Milvus, evaluating MinIO replacements, or weighing the operational trade-offs of different backends, we’d love to hear from you.
Join our[ Discord channel](https://discord.com/invite/8uyFbECzPX) and share your thoughts. You can also book a 20-minute one-on-one session to get insights, guidance, and answers to your questions through[ Milvus Office Hours](https://milvus.io/blog/join-milvus-office-hours-to-get-support-from-vectordb-experts.md).