MinIO deja de aceptar cambios de la comunidad: Evaluación de RustFS como backend de almacenamiento de objetos compatible con S3 para Milvus

Este post está escrito por Min Yin, uno de los colaboradores más activos de la comunidad de Milvus, y se publica aquí con permiso.

MinIO es un sistema de almacenamiento de objetos de código abierto, de alto rendimiento y compatible con S3, ampliamente utilizado en IA/ML, análisis y otras cargas de trabajo intensivas en datos. Para muchos despliegues de Milvus, también ha sido la opción por defecto para el almacenamiento de objetos. Recientemente, sin embargo, el equipo MinIO actualizó su GitHub README para indicar que este proyecto ya no acepta nuevos cambios.

En realidad, en los últimos años, MinIO ha cambiado gradualmente su atención hacia ofertas comerciales, ha endurecido su modelo de licencia y distribución y ha reducido el desarrollo activo en el repositorio de la comunidad. El paso del proyecto de código abierto al modo de mantenimiento es el resultado natural de esa transición más amplia.

Para los usuarios de Milvus que dependen de MinIO por defecto, este cambio es difícil de ignorar. El almacenamiento de objetos se encuentra en el corazón de la capa de persistencia de Milvus, y su fiabilidad a lo largo del tiempo depende no sólo de lo que funciona hoy, sino de si el sistema sigue evolucionando junto con las cargas de trabajo que soporta.

Con este telón de fondo, este artículo explora RustFS como una alternativa potencial. RustFS es un sistema de almacenamiento de objetos basado en Rust y compatible con S3 que hace hincapié en la seguridad de la memoria y en el diseño de sistemas modernos. Todavía está en fase experimental, y esta discusión no es una recomendación de producción.

La arquitectura de Milvus y dónde se sitúa el componente de almacenamiento de objetos

Milvus 2.6 adopta una arquitectura almacenamiento-computación totalmente desacoplada. En este modelo, la capa de almacenamiento se compone de tres componentes independientes, cada uno de los cuales desempeña una función distinta.

Etcd almacena metadatos, Pulsar o Kafka gestiona los registros de streaming, y el almacenamiento de objetos (normalmente MinIO o un servicio compatible con S3) proporciona una persistencia duradera para los datos vectoriales y los archivos de índice. Debido a que el almacenamiento y la computación están separados, Milvus puede escalar los nodos de computación de forma independiente mientras confía en un backend de almacenamiento compartido y fiable.

El papel del almacenamiento de objetos en Milvus

El almacenamiento de objetos es la capa de almacenamiento duradero en Milvus. Los datos vectoriales en bruto se conservan como binlogs, y las estructuras de índice como HNSW e IVF_FLAT también se almacenan allí.

Este diseño hace que los nodos de cálculo sean apátridas. Los nodos de consulta no almacenan datos localmente, sino que cargan segmentos e índices del almacenamiento de objetos bajo demanda. Como resultado, los nodos pueden escalar libremente hacia arriba o hacia abajo, recuperarse rápidamente de los fallos y soportar el equilibrio de carga dinámica en todo el clúster sin reequilibrio de datos en la capa de almacenamiento.

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
│           └── ...

Por qué Milvus utiliza la API de S3

En lugar de definir un protocolo de almacenamiento personalizado, Milvus utiliza la API S3 como su interfaz de almacenamiento de objetos. S3 se ha convertido en el estándar de facto para el almacenamiento de objetos: los principales proveedores de nube como AWS S3, Alibaba Cloud OSS y Tencent Cloud COS lo soportan de forma nativa, mientras que los sistemas de código abierto como MinIO, Ceph RGW, SeaweedFS y RustFS son totalmente compatibles.

Al estandarizar en la API de S3, Milvus puede confiar en SDKs Go maduros y bien probados en lugar de mantener integraciones separadas para cada backend de almacenamiento. Esta abstracción también ofrece a los usuarios flexibilidad de despliegue: MinIO para desarrollo local, almacenamiento de objetos en la nube en producción, o Ceph y RustFS para entornos privados. Mientras esté disponible un punto final compatible con S3, Milvus no necesita saber -o no le importa- qué sistema de almacenamiento se utiliza por debajo.

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

Evaluación de RustFS como backend de almacenamiento de objetos compatible con S3 para Milvus

Visión general del proyecto

RustFS es un sistema distribuido de almacenamiento de objetos escrito en Rust. Actualmente se encuentra en fase alfa (versión 1.0.0-alpha.68) y pretende combinar la simplicidad operativa de MinIO con los puntos fuertes de Rust en cuanto a seguridad de memoria y rendimiento. Más detalles en GitHub.

RustFS todavía está en desarrollo activo, y su modo distribuido aún no se ha publicado oficialmente. Como resultado, RustFS no se recomienda para la producción o cargas de trabajo de misión crítica en esta etapa.

Diseño de la arquitectura

RustFS sigue un diseño conceptualmente similar a MinIO. Un servidor HTTP expone una API compatible con S3, mientras que un Gestor de Objetos gestiona los metadatos de los objetos y un Motor de Almacenamiento es responsable de la gestión de los bloques de datos. En la capa de almacenamiento, RustFS se basa en sistemas de archivos estándar como XFS o ext4.

Para su modo distribuido previsto, RustFS pretende utilizar etcd para la coordinación de metadatos, con múltiples nodos RustFS formando un clúster. Este diseño se alinea estrechamente con las arquitecturas comunes de almacenamiento de objetos, haciendo que RustFS resulte familiar a los usuarios con experiencia en MinIO.

Compatibilidad con Milvus

Antes de considerar RustFS como un backend alternativo de almacenamiento de objetos, es necesario evaluar si cumple con los requisitos centrales de almacenamiento de Milvus.

Requisitos de Milvus	API S3	Compatibilidad con RustFS
Persistencia de datos vectoriales	PutObject, GetObject	✅ Totalmente compatible
Gestión de archivos de índice	ListObjects, DeleteObject	✅ Totalmente compatible
Operaciones de fusión de segmentos	Carga multiparte	✅ Totalmente compatible
Garantías de coherencia	Lectura y escritura sólidas	Consistencia fuerte (nodo único)

Sobre la base de esta evaluación, la implementación actual de la API S3 de RustFS satisface los requisitos funcionales básicos de Milvus. Esto la hace adecuada para pruebas prácticas en entornos que no sean de producción.

Práctica: Sustitución de MinIO por RustFS en Milvus

El objetivo de este ejercicio es reemplazar el servicio predeterminado de almacenamiento de objetos MinIO e implementar Milvus 2.6.7 utilizando RustFS como backend de almacenamiento de objetos.

Requisitos previos

1. Docker y Docker Compose están instalados (versión ≥ 20.10), y el sistema puede extraer imágenes y ejecutar contenedores normalmente.

2. Hay un directorio local disponible para el almacenamiento de datos de objetos, como /volume/data/ (o una ruta personalizada).

3. El puerto 9000 del host está abierto para el acceso externo, o un puerto alternativo está configurado en consecuencia.

4. El contenedor RustFS se ejecuta como usuario no root (rustfs). Asegúrese de que el directorio de datos del host pertenece al UID 10001.

Paso 1: Crear el directorio de datos y establecer los permisos

# 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

Descargar el archivo oficial Docker Compose

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

Paso 2: Modificar el Servicio de Almacenamiento de Objetos

Definir el Servicio RustFS

Nota: Asegúrese de que la clave de acceso y la clave secreta coinciden con las credenciales configuradas en el servicio 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

Complete la configuración

Nota: La configuración de almacenamiento de Milvus actualmente asume valores predeterminados estilo MinIO y aún no permite valores personalizados de clave de acceso o clave secreta. Cuando utilice RustFS como reemplazo, debe utilizar las mismas credenciales por defecto esperadas por 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

Inicie los Servicios

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

Compruebe el estado del servicio

docker-compose ps -a

Acceda a la interfaz web de RustFS

Abra la interfaz web de RustFS en su navegador: http://localhost:9001

Inicie sesión utilizando las credenciales por defecto: el nombre de usuario y la contraseña son minioadmin.

Pruebe el servicio 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", ...}) # Prueba de carga (arranque en frío + dos arranques en caliente) collection.release() load_times = [] for i in range(3): if i > 0: collection.release(); time.sleep(2) collection.load() load_times.append(...) # Prueba de consulta 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).