MinIO Alternatives Benchmarked: RustFS vs SeaweedFS vs MinIO

Why look for a MinIO alternative?

MinIO's open-source community edition was put into maintenance mode in December 2025 and its repository was later archived; the community edition is now distributed as source code only, and the official Docker images are no longer available (sources). Anyone running MinIO for development, CI or self-hosted storage needs either a maintained S3-compatible replacement or to build and patch MinIO themselves. RustFS and SeaweedFS are the two names that come up most, so this benchmark puts both next to MinIO's last community release under identical conditions, using only defaults.

Which MinIO alternative is fastest?

Large objects: RustFS and MinIO are in the same league; SeaweedFS is not. RustFS uploaded 8 MiB objects 3.0× faster than SeaweedFS and a 256 MiB multipart object 2.2× faster, with p99 8 MiB upload latency of 158 ms against SeaweedFS's 581 ms, and this held in every run. Against MinIO it is a tie: MinIO's medians are 17% higher on the multipart upload and 23% higher reading it back, but the run-to-run ranges overlap.

Small objects: SeaweedFS is the fastest at writing 64 KiB objects (1.8× RustFS, 2.0× MinIO) with the lowest p99. RustFS is the fastest at reading them (23% ahead of MinIO, 1.3× SeaweedFS). Both results held in every run.

The GET ranges for 8 MiB and 256 MiB objects are wide (see the min–max brackets), and some upload ranges span up to 2× between runs, so only differences where the ranges do not overlap are called out as wins here.

Which one uses the least memory and CPU?

Memory is where the three differ most. RustFS peaked at 348 MiB and MinIO at 394 MiB, while SeaweedFS in weed mini mode (master, volume server, filer and S3 gateway in one process) reached ~1.4 GiB, consistently across all five runs. On a small VM or a laptop running other containers, that difference matters more than any throughput number. CPU follows the same pattern: for the identical workload SeaweedFS used 15.5 CPU-seconds against 10.0 for RustFS and 8.3 for MinIO; the SeaweedFS gap held in every run, while RustFS and MinIO overlap. None of the three used noticeable extra disk space.

Startup was measured by a probe started right after docker run, so the probe's own few hundred milliseconds of start-up are not counted and the numbers are lower bounds. They were also noisy (single runs took seconds), but the order was clear: RustFS answered at a median of 32 ms (already up when the probe arrived), MinIO at 237 ms and SeaweedFS after about 1.1 s.

Are RustFS and SeaweedFS S3-compatible enough to replace MinIO?

For the S3 features most applications depend on, all three behave the same. The differences are at the edges:

• Metadata in presigned URLs: if you presign a PUT with Metadata, the SDK puts the x-amz-meta-* values into the URL's query string. MinIO stores them; RustFS and SeaweedFS accept the upload but drop the metadata. Set metadata server-side (PutObject, CopyObject) if you rely on it.
• Bucket CORS on MinIO: MinIO returns NotImplemented for PutBucketCors. It answers browser preflights anyway (it allows all origins by default), so browser uploads work, but per-bucket CORS rules are not supported. RustFS and SeaweedFS store and enforce them.

Do they lose data when the process crashes?

Every store recovered every acknowledged write after being killed, both mid-write and immediately after the last acknowledgement. That is the failure a development box or a crashing container sees. It is not a power-loss test (see Limitations), and on a single node there is no redundancy: losing the disk loses the data with any of these.

Which one should you pick?

• RustFS if you want a MinIO-shaped drop-in: single binary, similar memory and speed, the same S3 behaviour for common operations. It is young (1.0 GA on 16 September 2026, three patch releases in the month since), so pin a version and re-test before upgrading.
• SeaweedFS if you mostly store many small files, or want a project with more than a decade of production use and features beyond S3 (filer, FUSE mount, tiering). Budget ~1.4 GiB of RAM even for a single-node weed mini, and expect slower large uploads with default settings.
• MinIO from source if you need its exact behaviour today, accepting that the community edition no longer gets regular updates or security fixes.

How the benchmark was run

• Single node, single drive, out-of-the-box settings for every store: RustFS default container, SeaweedFS weed mini, MinIO server /data. No tuning.
• MinIO is built from source at the last community release tag (RELEASE.2025-10-15T17-29-55Z), because the community edition no longer ships official binaries or images.
• The client (Node v24.22.0, AWS SDK for JavaScript v3) runs in a container on the same Docker network as the store, so no host port-forwarding sits in the data path. Client and store share the same 8 vCPUs.
• Workload: 607 MiB of random, incompressible data. 500 × 64 KiB objects (16 concurrent), 40 × 8 MiB objects (4 concurrent), and one 256 MiB multipart upload in 16 MiB parts (4 concurrent). Each object is written, then read back.
• Every run uses a fresh container and volume, a discarded warm-up pass, then a measured pass. Stores are interleaved and the order rotates each iteration (5 iterations), so thermal throttling or background noise is not one store's bias.
• Memory is the container cgroup's anon (process heap, excluding page cache), sampled roughly once a second during the measured pass, so the peak is a lower bound. CPU is the cgroup's usage_usec delta over the measured pass, reported as total CPU-seconds for the workload.
• Crash durability: 8 writers upload 256–280 KiB objects for 4 s while the store is killed with kill -9 either mid-write or right after the last acknowledgement; after restart every acknowledged object is read back and its SHA-256 checked.

Limitations

• One machine (Apple Silicon laptop, Docker Desktop VM). Absolute numbers will differ on Linux servers and NVMe; the relative picture is what this measures.
• kill -9 kills the process, not the machine: the VM's page cache survives, so this shows crash recovery, not power-loss durability or fsync behaviour.
• Single node only. Erasure coding, replication, healing and multi-node failure handling are not exercised.
• Defaults only. Each store can be tuned (cache sizes, concurrency, SeaweedFS volume layout), which can move the numbers.

Reproduce it

Everything (harness, MinIO build, raw results) is in iamkunal9/minio-alternatives-benchmark (v1.1). With Docker and Node installed:

git clone https://github.com/iamkunal9/minio-alternatives-benchmark.git && cd minio-alternatives-benchmark
git checkout v1.1 && npm ci
./run.sh                  # ~35 min: 5 interleaved runs per store + crash cycles
node bench/report.mjs     # results/RESULTS.md + results/summary.json

Pin newer versions in run.sh to re-test; results land in results/.

FAQ

What is the best MinIO alternative in 2026?

For a single-node MinIO replacement with a similar footprint, RustFS 1.0.3 came closest in this benchmark: throughput on par with MinIO (medians within ±25%, mostly inside run-to-run noise) and 348 MiB peak memory versus MinIO's 394 MiB. SeaweedFS 4.48 is the more mature project and was fastest for small 64 KiB uploads, but used about 4.3× more memory than RustFS under load and was 2–3× slower on large writes.

Is RustFS faster than MinIO?

Mostly they tie. With default settings on one node, RustFS was clearly faster only at reading 64 KiB objects (23%, in every run). Everything else fell within run-to-run noise: medians had RustFS 14% ahead on 64 KiB uploads, level on 8 MiB uploads, and MinIO 17% ahead on a 256 MiB multipart upload and 23% on reading it back.

Is SeaweedFS or RustFS faster?

RustFS was faster at large uploads in every run: 3.0× on 8 MiB objects and 2.2× on a 256 MiB multipart upload (median), and 1.3× on 64 KiB reads. SeaweedFS (weed mini) won 64 KiB uploads by 1.8× in every run, with lower p99 latency.

How much memory do RustFS and SeaweedFS need?

Idle, all three sat between 82 and 117 MiB. Under a 607 MiB mixed workload the peak was 348 MiB for RustFS, 394 MiB for MinIO and 1,480 MiB (~1.4 GiB) for SeaweedFS in weed mini mode.

Are RustFS and SeaweedFS S3-compatible?

Each store passed 14 of 15 S3 checks with the AWS SDK for JavaScript v3 (CORS, browser presigned PUT, CopyObject, Range GET, conditional GET, pagination, multipart + UploadPartCopy, tagging, versioning, batch delete). RustFS and SeaweedFS do not store x-amz-meta-* metadata that is signed into a presigned PUT URL (set metadata server-side instead); MinIO returns NotImplemented for PutBucketCors.

Do RustFS or SeaweedFS lose data on a crash?

Not in this test. Across 6 kill -9 cycles per store (mid-write and right after acknowledgement), RustFS kept 7,391 of 7,391, SeaweedFS 9,346 of 9,346 and MinIO 9,374 of 9,374 acknowledged objects intact. This covers process crashes, not power loss.

Can I still use MinIO's community edition?

The community repository entered maintenance mode in December 2025 and was later archived; the community edition is distributed as source code only. You can still build it from source (this benchmark does), but it no longer receives regular updates or security fixes.

Sources

• MinIO Is Dead, Long Live MinIO (Vonng)
• MinIO in Maintenance Mode (ayedo)
• minio/minio repository (archived)
• RustFS 1.0 reaches GA (Linuxiac)
• RustFS 1.0 is GA: what's production-ready and what isn't
• RustFS releases
• SeaweedFS repository
• Self-hosted S3 alternatives in 2026 (glukhov.org)