MinIO Berhenti Menerima Perubahan Komunitas: Mengevaluasi RustFS sebagai Backend Penyimpanan Objek yang Kompatibel dengan S3 untuk Milvus

Artikel ini ditulis oleh Min Yin, salah satu kontributor komunitas paling aktif di Milvus, dan dipublikasikan di sini dengan izin.

MinIO adalah sistem penyimpanan objek sumber terbuka, berkinerja tinggi, dan kompatibel dengan S3 yang banyak digunakan dalam AI/ML, analitik, dan beban kerja intensif data lainnya. Untuk banyak penerapan Milvus, MinIO juga telah menjadi pilihan default untuk penyimpanan objek. Namun, baru-baru ini, tim MinIO memperbarui README GitHub-nya untuk menyatakan bahwa proyek ini tidak lagi menerima perubahan baru.

Sebenarnya, selama beberapa tahun terakhir, MinIO secara bertahap mengalihkan perhatiannya ke penawaran komersial, memperketat model lisensi dan distribusinya, dan mengurangi pengembangan aktif di repositori komunitas. Memindahkan proyek sumber terbuka ke mode pemeliharaan adalah hasil alami dari transisi yang lebih luas tersebut.

Bagi pengguna Milvus yang mengandalkan MinIO secara default, perubahan ini sulit untuk diabaikan. Penyimpanan objek berada di jantung lapisan ketahanan Milvus, dan keandalannya dari waktu ke waktu tidak hanya bergantung pada apa yang berfungsi saat ini, tetapi juga pada apakah sistem terus berevolusi seiring dengan beban kerja yang didukungnya.

Dengan latar belakang ini, artikel ini mengeksplorasi RustFS sebagai alternatif yang potensial. RustFS adalah sistem penyimpanan objek berbasis Rust yang kompatibel dengan S3 yang menekankan keamanan memori dan desain sistem modern. Sistem ini masih bersifat eksperimental, dan diskusi ini bukan merupakan rekomendasi produksi.

Arsitektur Milvus dan Letak Komponen Penyimpanan Objek

Milvus 2.6 mengadopsi arsitektur komputasi-penyimpanan yang sepenuhnya terpisah. Dalam model ini, lapisan penyimpanan terdiri dari tiga komponen independen, masing-masing memiliki peran yang berbeda.

Etcd menyimpan metadata, Pulsar atau Kafka menangani log streaming, dan penyimpanan objek-biasanya MinIO atau layanan yang kompatibel dengan S3-menyediakan ketahanan yang tahan lama untuk data vektor dan file indeks. Karena penyimpanan dan komputasi dipisahkan, Milvus dapat menskalakan node komputasi secara independen sambil mengandalkan backend penyimpanan bersama yang andal.

Peran Penyimpanan Objek di Milvus

Penyimpanan objek adalah lapisan penyimpanan yang tahan lama di Milvus. Data vektor mentah disimpan sebagai binlog, dan struktur indeks seperti HNSW dan IVF_FLAT juga disimpan di sana.

Desain ini membuat node komputasi tidak memiliki status. Query Node tidak menyimpan data secara lokal; sebaliknya, mereka memuat segmen dan indeks dari penyimpanan objek sesuai permintaan. Hasilnya, node dapat meningkatkan atau menurunkan skala dengan bebas, pulih dengan cepat dari kegagalan, dan mendukung penyeimbangan beban dinamis di seluruh cluster tanpa menyeimbangkan kembali data di lapisan penyimpanan.

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

Mengapa Milvus Menggunakan API S3

Daripada mendefinisikan protokol penyimpanan khusus, Milvus menggunakan API S3 sebagai antarmuka penyimpanan objek. S3 telah menjadi standar de facto untuk penyimpanan objek: penyedia cloud utama seperti AWS S3, Alibaba Cloud OSS, dan Tencent Cloud COS mendukungnya secara native, sementara sistem open-source seperti MinIO, Ceph RGW, SeaweedFS, dan RustFS sepenuhnya kompatibel.

Dengan melakukan standarisasi pada API S3, Milvus dapat mengandalkan Go SDK yang sudah matang dan teruji dengan baik alih-alih mempertahankan integrasi terpisah untuk setiap backend penyimpanan. Abstraksi ini juga memberikan fleksibilitas penerapan kepada pengguna: MinIO untuk pengembangan lokal, penyimpanan objek cloud dalam produksi, atau Ceph dan RustFS untuk lingkungan pribadi. Selama endpoint yang kompatibel dengan S3 tersedia, Milvus tidak perlu mengetahui - atau peduli - sistem penyimpanan apa yang digunakan di bawahnya.

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

Mengevaluasi RustFS sebagai Backend Penyimpanan Objek yang Kompatibel dengan S3 untuk Milvus

Gambaran Umum Proyek

RustFS adalah sistem penyimpanan objek terdistribusi yang ditulis dalam bahasa pemrograman Rust. Saat ini masih dalam tahap alfa (versi 1.0.0-alpha.68) dan bertujuan untuk menggabungkan kesederhanaan operasional MinIO dengan kekuatan Rust dalam hal keamanan dan kinerja memori. Informasi lebih lanjut tersedia di GitHub.

RustFS masih dalam pengembangan aktif, dan mode distribusinya belum dirilis secara resmi. Oleh karena itu, RustFS tidak direkomendasikan untuk produksi atau beban kerja yang sangat penting pada tahap ini.

Desain Arsitektur

RustFS mengikuti desain yang secara konseptual mirip dengan MinIO. Sebuah server HTTP mengekspos API yang kompatibel dengan S3, sementara Object Manager menangani metadata objek, dan Storage Engine bertanggung jawab untuk manajemen blok data. Pada lapisan penyimpanan, RustFS mengandalkan sistem berkas standar seperti XFS atau ext4.

Untuk mode terdistribusi yang direncanakan, RustFS bermaksud untuk menggunakan etcd untuk koordinasi metadata, dengan beberapa node RustFS yang membentuk sebuah kluster. Desain ini selaras dengan arsitektur penyimpanan objek yang umum, membuat RustFS akrab dengan pengguna yang berpengalaman dengan MinIO.

Kompatibilitas dengan Milvus

Sebelum mempertimbangkan RustFS sebagai backend penyimpanan objek alternatif, perlu untuk mengevaluasi apakah RustFS memenuhi persyaratan penyimpanan inti Milvus.

Persyaratan Milvus	API S3	Dukungan RustFS
Persistensi data vektor	PutObject, GetObject	✅ Didukung penuh
Manajemen file indeks	ListObjects, DeleteObject	✅ Didukung penuh
Operasi penggabungan segmen	Unggahan Multipart	✅ Didukung penuh
Jaminan konsistensi	Baca-setelah-tulis yang kuat	Konsistensi yang kuat (simpul tunggal)

Berdasarkan evaluasi ini, implementasi API S3 RustFS saat ini memenuhi persyaratan fungsional dasar Milvus. Hal ini membuatnya cocok untuk pengujian praktis di lingkungan non-produksi.

Praktik Langsung: Mengganti MinIO dengan RustFS di Milvus

Tujuan dari latihan ini adalah untuk mengganti layanan penyimpanan objek MinIO default dan menerapkan Milvus 2.6.7 menggunakan RustFS sebagai backend penyimpanan objek.

Prasyarat

1. Docker dan Docker Compose telah terinstal (versi ≥ 20.10), dan sistem dapat menarik citra dan menjalankan kontainer secara normal.

2. Direktori lokal tersedia untuk penyimpanan data objek, seperti /volume/data/ (atau jalur khusus).

3. Port host 9000 terbuka untuk akses eksternal, atau port alternatif dikonfigurasikan dengan tepat.

4. Kontainer RustFS berjalan sebagai pengguna non-root (rustfs). Pastikan direktori data hos dimiliki oleh UID 10001.

Langkah 1: Membuat Direktori Data dan Mengatur Izin

# 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

Unduh berkas penulisan Docker Resmi

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

Langkah 2: Memodifikasi Layanan Penyimpanan Objek

Tentukan Layanan RustFS

Catatan: Pastikan kunci akses dan kunci rahasia sesuai dengan kredensial yang dikonfigurasi dalam layanan 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

Konfigurasi Lengkap

Catatan: Konfigurasi penyimpanan Milvus saat ini mengasumsikan default gaya MinIO dan belum mengizinkan nilai kunci akses atau kunci rahasia khusus. Ketika menggunakan RustFS sebagai pengganti, ia harus menggunakan kredensial default yang sama dengan yang diharapkan oleh 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

Mulai Layanan

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

Periksa Status Layanan

docker-compose ps -a

Mengakses Antarmuka Web RustFS

Buka antarmuka web RustFS di peramban Anda: http://localhost:9001

Masuk menggunakan kredensial default: nama pengguna dan kata sandi keduanya adalah minioadmin.

Menguji Layanan 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(...) # Menyisipkan tes 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 # Pembuatan indeks collection.flush() collection.create_index(field_name = "embedding", index_params = {"index_type": "HNSW", ...}) # Load test (cold start + dua warm start) collection.release() load_times = [] for i in range(3): if i > 0: collection.release(); time.sleep(2) collection.load() load_times.append(...) # Uji coba kueri search_times = [] for _ in range(3): collection.search(kueri, 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).