On this page
Updated 2026-10-18 for Loams 0.1.0
Changed: in the 0.1.0 compose stack RustFS 1.0.0 already backs Loams Postgres's storage, while the engine's bucket defaults to a local directory (any S3 endpoint, RustFS included, works); the "managed cloud" framing became self-hosted plus our hosted console.
In a cloud account, Loams’ 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 Loams 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 Loams | Loams Postgres storage in the 0.1.0 stack Default engine store and per-PR 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 Loams needs from any object store
Loams’ durable state is a bucket, so it relies on a handful of S3 behaviours being exactly right:
| Behaviour | Why Loams 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 |
Loams reaches every store the same way, through the object_store crate (Apache-2.0), DataFusion's native I/O layer, wrapped in Loams’ loams-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 Loams 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 Loams’ 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 Loams’ 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 Loams uses it
The decision to make RustFS the default local and self-hosted store is approved (D61); the work lands with the engine's production-hardening phase. Update for 0.1.0: the release compose stack runs rustfs/rustfs:1.0.0 as the object store under Loams Postgres. The engine's own bucket (LOAMS_BUCKET) defaults to a local directory on a volume; point it at RustFS, S3, R2, GCS, Azure or MinIO when you want an object store. A RustFS-backed nightly job also runs Loams Git's tests.
- Development and CI. RustFS replaces MinIO in the docs and development tooling. The Neon and MySQL spikes (platform part 7) already ran on RustFS 1.0.0.
- A conformance target on every pull request. A new provider conformance suite for Loams’
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. Loams 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 Loams read runs on: Apache DataFusion, and the Arrow format underneath it.