MinIO deixa de aceitar alterações da comunidade: Avaliando o RustFS como um backend viável de armazenamento de objetos compatível com S3 para o Milvus

Este post foi escrito por Min Yin, um dos colaboradores mais activos da comunidade de Milvus, e é publicado aqui com permissão.

O MinIO é um sistema de armazenamento de objetos de código aberto, de alto desempenho e compatível com S3, amplamente utilizado em IA/ML, análises e outras cargas de trabalho com uso intensivo de dados. Para muitas implantações do Milvus, ele também tem sido a escolha padrão para o armazenamento de objetos. Recentemente, no entanto, a equipe MinIO atualizou seu GitHub README para afirmar que este projeto não está mais aceitando novas alterações.

Na verdade, ao longo dos últimos anos, o MinIO mudou gradualmente a sua atenção para ofertas comerciais, apertou o seu modelo de licenciamento e distribuição, e reduziu o desenvolvimento ativo no repositório da comunidade. Passar o projeto de código aberto para o modo de manutenção é o resultado natural dessa transição mais ampla.

Para os utilizadores do Milvus que dependem do MinIO por defeito, esta mudança é difícil de ignorar. O armazenamento de objetos está no coração da camada de persistência do Milvus, e sua confiabilidade ao longo do tempo depende não apenas do que funciona hoje, mas se o sistema continua a evoluir junto com as cargas de trabalho que suporta.

Neste contexto, este artigo explora o RustFS como uma alternativa potencial. O RustFS é um sistema de armazenamento de objectos baseado em Rust e compatível com S3 que enfatiza a segurança da memória e o design de sistemas modernos. Ele ainda é experimental, e esta discussão não é uma recomendação de produção.

A arquitetura do Milvus e onde fica o componente de armazenamento de objetos

O Milvus 2.6 adota uma arquitetura de armazenamento-computação totalmente desacoplada. Neste modelo, a camada de armazenamento é composta por três componentes independentes, cada um com uma função distinta.

Etcd armazena metadados, Pulsar ou Kafka lida com logs de streaming, e armazenamento de objetos - normalmente MinIO ou um serviço compatível com S3 - fornece persistência durável para dados vetoriais e arquivos de índice. Como o armazenamento e a computação são separados, o Milvus pode escalar os nós de computação de forma independente, enquanto depende de um back-end de armazenamento compartilhado e confiável.

O papel do armazenamento de objectos em Milvus

O armazenamento de objectos é a camada de armazenamento durável em Milvus. Os dados vetoriais brutos são persistidos como binlogs, e estruturas de índice como HNSW e IVF_FLAT também são armazenadas lá.

Este design torna os nós de computação stateless. Os nós de consulta não armazenam dados localmente; em vez disso, eles carregam segmentos e índices do armazenamento de objetos sob demanda. Como resultado, os nós podem aumentar ou diminuir livremente, recuperar-se rapidamente de falhas e suportar o balanceamento dinâmico de carga em todo o cluster sem rebalanceamento de dados na camada de armazenamento.

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 que Milvus usa a API S3

Em vez de definir um protocolo de armazenamento personalizado, o Milvus utiliza a API S3 como interface de armazenamento de objectos. O S3 se tornou o padrão de fato para armazenamento de objetos: os principais provedores de nuvem, como AWS S3, Alibaba Cloud OSS e Tencent Cloud COS, o suportam nativamente, enquanto sistemas de código aberto como MinIO, Ceph RGW, SeaweedFS e RustFS são totalmente compatíveis.

Ao padronizar a API S3, o Milvus pode confiar em SDKs Go maduros e bem testados, em vez de manter integrações separadas para cada back-end de armazenamento. Essa abstração também oferece aos usuários flexibilidade de implantação: MinIO para desenvolvimento local, armazenamento de objetos na nuvem em produção, ou Ceph e RustFS para ambientes privados. Desde que um endpoint compatível com S3 esteja disponível, Milvus não precisa saber - ou se importar - qual sistema de armazenamento é usado por baixo.

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

Avaliando o RustFS como um backend de armazenamento de objetos compatível com S3 para o Milvus

Visão geral do projeto

RustFS é um sistema de armazenamento de objetos distribuído escrito em Rust. Está atualmente na fase alfa (versão 1.0.0-alpha.68) e tem como objetivo combinar a simplicidade operacional do MinIO com os pontos fortes do Rust em termos de segurança de memória e desempenho. Mais detalhes estão disponíveis no GitHub.

O RustFS ainda está em desenvolvimento ativo, e o seu modo distribuído ainda não foi oficialmente lançado. Como resultado, o RustFS não é recomendado para produção ou cargas de trabalho de missão crítica nesta fase.

Projeto de arquitetura

O RustFS segue um design que é concetualmente semelhante ao MinIO. Um servidor HTTP expõe uma API compatível com S3, enquanto um Object Manager trata dos metadados dos objectos e um Storage Engine é responsável pela gestão dos blocos de dados. Na camada de armazenamento, o RustFS depende de sistemas de ficheiros padrão, como o XFS ou o ext4.

Para seu modo distribuído planejado, o RustFS pretende usar o etcd para coordenação de metadados, com múltiplos nós RustFS formando um cluster. Este design alinha-se de perto com as arquitecturas comuns de armazenamento de objectos, tornando o RustFS familiar para os utilizadores com experiência MinIO.

Compatibilidade com Milvus

Antes de considerar o RustFS como um backend de armazenamento de objetos alternativo, é necessário avaliar se ele atende aos requisitos principais de armazenamento do Milvus.

Requisitos do Milvus	API S3	Suporte RustFS
Persistência de dados vectoriais	PutObject, GetObject	Totalmente suportado
Gestão de ficheiros de índice	ListObjects, DeleteObject	Totalmente suportado
Operações de fusão de segmentos	Upload de várias partes	Totalmente suportado
Garantias de consistência	Forte leitura após escrita	Consistência forte (nó único)

Com base nessa avaliação, a implementação atual da API S3 do RustFS satisfaz os requisitos funcionais básicos do Milvus. Isso o torna adequado para testes práticos em ambientes de não produção.

Hands-On: substituindo MinIO por RustFS em Milvus

O objetivo deste exercício é substituir o serviço de armazenamento de objetos MinIO padrão e implantar o Milvus 2.6.7 usando o RustFS como backend de armazenamento de objetos.

Pré-requisitos

1. O Docker e o Docker Compose estão instalados (versão ≥ 20.10), e o sistema pode puxar imagens e executar contêineres normalmente.

2. Um diretório local está disponível para armazenamento de dados de objeto, como /volume/data/ (ou um caminho personalizado).

3. A porta 9000 do host está aberta para acesso externo, ou uma porta alternativa é configurada de acordo.

4. O contentor RustFS é executado como um utilizador não-root (rustfs). Certifique-se de que o diretório de dados do host seja de propriedade do UID 10001.

Etapa 1: criar o diretório de dados e definir permissões

# 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

Baixe o arquivo oficial do Docker Compose

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

Etapa 2: Modificar o serviço de armazenamento de objetos

Definir o serviço RustFS

Nota: Certifique-se de que a chave de acesso e a chave secreta correspondem às credenciais configuradas no serviço 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

Configuração completa

Observação: a configuração de armazenamento do Milvus atualmente assume padrões no estilo MinIO e ainda não permite valores personalizados de chave de acesso ou chave secreta. Ao usar o RustFS como substituto, ele deve usar as mesmas credenciais padrão esperadas pelo 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

Iniciar os serviços

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

Verificar o estado do serviço

docker-compose ps -a

Aceder à interface Web do RustFS

Abra a interface Web do RustFS no seu browser: http://localhost:9001

Inicie sessão utilizando as credenciais predefinidas: o nome de utilizador e a palavra-passe são ambos minioadmin.

Testar o serviço 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(...) # Teste de inserção 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 # Construção do índice collection.flush() collection.create_index(field_name="embedding", index_params={"index_type": "HNSW", ...}) # Teste de carga (arranque a frio + dois arranques a quente) collection.release() load_times = [] for i in range(3): if i > 0: collection.release(); time.sleep(2) collection.load() load_times.append(...) # Teste 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).