A License That Gives Legal Teams Headaches
Imagine a company wants to self-host object storage. At the technology selection meeting, an engineer says: "Let's use MinIO — written in Go, S3-compatible, active community." Then legal reads the license line and goes pale: AGPLv3.
The power of AGPL lies in its "network use clause." GPL only triggers open-source obligations when software is distributed; AGPL also triggers when you "provide a service over a network." This means if you build an S3 service with MinIO and offer it externally, your entire server-side code — including business logic calling MinIO — theoretically has to be open-sourced.
Large companies' legal departments dread AGPL. Google bans AGPL dependencies internally. Alibaba, Tencent, and ByteDance have similar internal red lines. The result: no matter how powerful or fast MinIO is, many enterprises simply dare not touch it.
Alternatives are scarce. Ceph is too heavy and complex to deploy, suited for hyperscale scenarios. AWS S3 is too expensive. Building in-house? Most lack that engineering capability.
That's the gap rustfs/rustfs targets: rewrite a MinIO equivalent in Rust, released under the Apache 2.0 license.
What Is RustFS?
In one sentence: RustFS is an S3-compatible, distributed object storage system written in Rust, under the Apache 2.0 license.
Its positioning is crystal clear — benchmark against MinIO, but differentiate on two dimensions:
1. License: Apache 2.0 (permissive, business-friendly) vs MinIO's AGPLv3 (copyleft, commercially restrictive) 2. Language: Rust (memory safety + zero-cost abstractions) vs Go (GC + runtime)
These two differences reinforce each other. AGPL makes enterprises afraid to use MinIO; Apache 2.0 makes them comfortable with RustFS. Rust's memory safety makes RustFS safer at the systems level than Go (no data races, no null pointer dereferences), while performance is roughly comparable — Go's GC isn't a bottleneck in I/O-heavy object storage workloads, but Rust's zero-cost abstractions make lock-free data structures and allocation-free hot paths possible.
Feature Matrix: Full Parity with MinIO
RustFS's feature table reads like a mirror of MinIO's:
| Feature | RustFS | Notes | |------|--------|------| | S3 Core API | ✅ | Full S3 compatibility | | Distributed mode | ✅ | Horizontal scaling | | Single-node mode | ✅ | Small deployments | | Versioning | ✅ | Object history | | Object Lock (WORM) | ✅ | Compliance retention | | Server-side encryption | ✅ | SSE-S3/SSE-KMS | | Bitrot protection | ✅ | Silent corruption detection | | Erasure coding + self-healing | ✅ | Data redundancy | | Bucket replication | ✅ | Cross-region sync | | Site replication | ✅ | Multi-site DR | | Lifecycle management | ✅ | Auto-tiering/expiry | | IAM/policies | ✅ | Fine-grained permissions | | OIDC/SSO | ✅ | Enterprise identity integration | | OpenStack Swift API | ✅ | Multi-protocol support | | SFTP/FTPS/WebDAV | ✅ | File protocols | | K8s Helm | ✅ | Cloud-native deployment | | S3 Tables (Iceberg REST) | 🧪 Preview | Data lake native |
This table covers nearly all of MinIO's core features. The last row, S3 Tables (Iceberg REST), deserves special attention — it's a key step in object storage's evolution toward data lakes.
S3 Tables: Object Storage Goes Data Lake
At AWS re:Invent 2024, S3 Tables was announced, natively integrating the Iceberg table format into S3. This means you no longer need a separate Iceberg catalog service (Glue, Nessie, Polaris) — S3 itself manages table metadata and manifests.
This is revolutionary for data lake architecture. The old pipeline was: S3 stores data files → Glue/Nessie stores metadata → Spark/Trino queries. S3 Tables removes the middle layer: S3 Tables stores data + metadata → Spark/Trino queries directly.
RustFS brings this capability to the open-source world. Its S3 Tables implementation is Iceberg REST Catalog compatible, meaning PyIceberg, DuckDB, and Spark can connect directly. For teams building self-hosted data lakes, this is big news — no AWS needed, no Glue to set up; one RustFS cluster covers it all.
The feature is currently in Preview, but the direction is clear: object storage is evolving from "storing files" to "storing tables." RustFS is advancing along this path in sync with MinIO, but with Apache 2.0 lowering the adoption barrier.
Bitrot Protection: The Silent Data Killer
Object storage has an overlooked problem: data rots on its own.
Not explicit disk failures, but bit rot — a bit on a disk or SSD flips by itself, undetectable by the filesystem, and file content silently changes. Your backups contain the same corrupt data, because backups are "faithful copies."
For personal users, bit rot might strike once every few years. But on petabyte-scale object storage, hundreds of bits may be silently flipping every day. Without checksums, your data is slowly decaying and you don't even know it.
RustFS's Bitrot Protection computes checksums for each object block using SHA-256 or Highway Hash, verified on read. This mirrors MinIO's Bitrot approach in spirit, but Rust's implementation can leverage compile-time optimizations — SIMD instructions for hash algorithms are directly accessible via std::simd in Rust, while Go depends on assembly or cgo.
Rust vs Go: The Language Choice for Object Storage
MinIO uses Go; RustFS uses Rust. The logic behind this choice is worth unpacking.
Go's advantages:
- Fast development (simple syntax, fast compilation)
- Mature concurrency model (goroutines + channels)
- Rich ecosystem (S3 SDKs, gRPC, etcd all have mature Go libraries)
- Simple deployment (single binary)
- Memory safety (compile-time guarantees against data races)
- Zero-cost abstractions (no GC, no runtime)
- Predictable performance (no GC pauses)
- Systems programming capability (direct hardware access, memory mapping)
- CPU: 2-core Intel Xeon Sapphire Rapids 8475B
- Memory: 4GB
- Network: 15Gbps
- Disks: 4 × 40GB SSD, 3800 IOPS each
Rust's advantages:
Object storage's core workload is I/O — disk reads/writes, network transfer, checksum computation. These are CPU + I/O intensive, and GC pauses have limited impact (most time is spent waiting on I/O). So RustFS's main motivation for Rust is likely not performance, but memory safety.
Object storage systems are critical attack-surface nodes — they store user data, handle authentication, and expose APIs. A memory safety bug (like a buffer overflow) can lead to data leaks or RCE. Rust eliminates such bugs at compile time; Go relies on runtime checks (and some checks fall short, like data races).
So RustFS's logic is: the license (Apache 2.0) solves the business problem; the language (Rust) solves the security problem. Together, they form differentiated competition against MinIO.
Performance Comparison: Video Beats Text
RustFS's README embeds a stress-test video comparing RustFS and MinIO throughput on identical hardware. Test environment:
The video can't be shown here, but the very fact that the RustFS team published this comparison is a signal — they're confident they can beat MinIO in public benchmarks. MinIO hasn't publicly responded to the comparison, which is itself a response.
The License War: AGPL vs Apache 2.0
One line from RustFS's README deserves highlighting:
> RustFS is released under the permissible Apache 2.0 license, avoiding the restrictions of AGPL.
This isn't a technical statement — it's a business statement. It tells enterprise users: you can use RustFS with confidence, without worrying about viral open-source obligations.
The AGPL vs Apache 2.0 debate has raged in open-source communities for twenty years. AGPL supporters (including MongoDB, Elastic, MinIO) argue that cloud vendors (AWS, Alibaba Cloud) profit from hosting open-source projects without giving back, and AGPL is the only license that stops this "bleeding." Apache 2.0 supporters argue AGPL scares off enterprise users too, and projects ultimately fail to grow.
Both sides have a point, but the results are telling — MongoDB's stock rose after switching from AGPL to SSPL; after Elastic switched from Apache to AGPL, AWS forked Elasticsearch outright (OpenSearch). MinIO remains active under AGPL, but enterprise adoption is indeed constrained.
RustFS choosing Apache 2.0 is pragmatic — it wants enterprise adoption, not license purity. Whether this choice sustains its business model remains to be seen.
Object Storage's Rust Moment
Over the past few years, Rust has steadily encroached on C/C++ territory in systems programming. The Linux kernel accepted Rust, the Windows kernel accepted Rust, Cloudflare wrote an Nginx replacement in Rust (Pingora), AWS wrote Firecracker in Rust.
Object storage is the next target on this path. MinIO proved "writing object storage in a modern systems language" is viable with Go; RustFS proves "rewriting on top of MinIO's foundation with a memory-safe language" is also viable.
The significance goes beyond "switching languages." Object storage is the cornerstone of cloud-native architecture — Kubernetes persistent volumes, AI training data pipelines, and data lake storage layers all depend on it. If this cornerstone migrates from Go to Rust, the memory safety of the entire cloud-native stack rises a level.
RustFS is still early-stage (298 stars today vs MinIO's 50k+), but the direction is clear and execution is solid. Apache 2.0 + Rust + S3 compatibility + Iceberg REST — that four-tag combination is unique in object storage. For teams wanting to self-host object storage without touching AGPL, RustFS is the most interesting option to watch in 2026.
---
Project: https://github.com/rustfs/rustfs Docs: https://docs.rustfs.com/ License: Apache 2.0 Language: Rust Stars at time of writing: 298 (2026-09-18 GitHub Trending)