On this page
In the managed cloud, Loam's bucket is S3, GCS or Azure Blob. On a laptop, in CI and in a self-hosted cluster, somebody has to provide an S3 endpoint. For Loam that will be RustFS.
| Repository | rustfs/rustfs |
| License | Apache-2.0 (contributions go through a CLA with RustFS, Inc.; a commercial license feature exists and is off by default) |
| Version checked | 1.0.0, released 2026-09-16 |
| In Loam | Default self-hosted store and CI target |
What it is
RustFS is an S3-compatible object storage server written in Rust. It runs as a single node with one drive, a single node with several drives, or a distributed cluster, and protects data with erasure coding: each object is split into data and parity shards spread across drives in an erasure set, so it survives the loss of as many drives as there are parity shards. Its README publishes an S3 compatibility matrix and marks erasure coding, single-node and distributed modes as available and gated by CI. It ships an upstream Helm chart. The 1.0 release in September 2026 is the first it calls production-ready.
What Loam needs from any object store
Loam's durable state is a bucket, so it relies on a handful of S3 behaviours being exactly right:
| Behaviour | Why Loam needs it |
|---|---|
Conditional PUT (If-None-Match: *, If-Match: <etag>) returning 412 on conflict | Immutable objects are created exactly once, and durable-execution documents are compare-and-swapped |
| Read-after-write and list-after-write consistency | A committed WAL object or manifest must be visible to the next reader, including across list pages |
| Ranged GETs | Readers fetch Lance pages and Tantivy split footers by byte range, never whole files |
| Stable ETags | Imports pin a file set by ETag, and conditional writes compare them |
| Durability on acknowledgement | An acknowledged PUT must survive a crash, including kill -9 of the storage process |
Loam reaches every store the same way, through the object_store crate (Apache-2.0), DataFusion's native I/O layer, wrapped in Loam's operon-store with fault injection for tests and a RAM and NVMe range cache on top. RustFS is one more S3 endpoint to it.
Why RustFS
For years the default answer for "S3 on my own machine" was MinIO. Two things changed. MinIO's community edition was AGPL-3.0, which Loam never linked but documented as the local store, it entered maintenance mode in December 2025, and the repository was archived on April 25, 2026. We needed a replacement that is:
- permissively licensed, because it ships in Loam's self-hosted bundle and every distributor of that bundle would otherwise carry AGPL obligations;
- actively maintained, with a clear release line;
- correct on conditional writes, since that is Loam's commit primitive.
RustFS is Apache-2.0, released 1.0 in September 2026, and its conditional writes return S3's 412 under a write lock. Ceph's RADOS Gateway is the mature alternative, and far heavier to run on a laptop or in a small cluster.
How Loam uses it
The decision to make RustFS the default local and self-hosted store is approved; the work lands with the engine's production-hardening phase.
- Development and CI. RustFS will replace MinIO in the docs and development tooling. The Neon and WeSQL spikes (platform part 7) already ran on RustFS 1.0.0.
- A conformance target on every pull request. A new provider conformance suite for Loam's
Storelayer, and the S3 fault matrix (timeouts, resets, throttling, conflicting writers), will run against RustFS on each change, and must produce the same expected table as the in-memory store. - The default in GitOps deployments, deployed by RustFS's own Helm chart in the first object-store wave, with a provider that creates buckets and credentials (platform part 8).
What we still have to verify
We do not take compatibility matrices on trust. The conformance suite has to check, on RustFS specifically:
- list-after-write, including across list pages;
- fsync durability in single-disk mode, by restarting and
kill -9-ing the container between a PUT's acknowledgement and a read; - ETag stability with server-side encryption on.
Things we learned running it
Two small incompatibilities turned up in the spikes, both worth knowing if you point other software at RustFS:
- RustFS rejects SigV4-signed requests that lack the
x-amz-content-sha256header. Old curl versions'--aws-sigv4option does not send it, so bucket-creation scripts need to add it. - Clients that always use virtual-hosted-style URLs (
<bucket>.<host>), such as the AWS C++ SDK, need RustFS told its domain (RUSTFS_SERVER_DOMAINS) and a DNS alias for the bucket host.
Limits
From RustFS's own documentation and our reading of it:
- A single-node, single-drive deployment cannot be expanded in place. Choose the layout you will grow into.
- When a cluster is expanded, a new pool must keep the endpoint layout and erasure-set width.
- Reading MinIO's on-disk data is a preview feature, and objects MinIO encrypted are not readable by RustFS. Migrating from MinIO means copying through the S3 API.
- The 1.0 line is weeks old. Loam pins a version, and keeps plain S3, GCS and Azure as providers behind the same interface.
The next post moves up the stack to the query engine every Loam read runs on: Apache DataFusion, and the Arrow format underneath it.