Compare the guarantee before the speed.
One panel measures local power-loss durability. The other measures remote durability on the same RustFS server. Results from these lanes are never pooled.
No validated measurements are published yet.
The participant contract and strict artifact validator are present. A number will appear only after correctness preflight, matched host and power metadata, retained raw samples, and artifact validation.
Local durable commit
This lane compares one mutation per transaction on one writer. Each success includes the participant's qualified local durability barrier. A later reopen verifies every value outside the timed region.
| Engine | Storage profile | Eligibility | Current result |
|---|---|---|---|
| Flyology.DB | Flyology Object Storage Files with power-loss-durable commit policy | Eligible | Awaiting campaign |
| SlateDB | object_store LocalFileSystem with fsync enabled | Eligible | Awaiting campaign |
| TidesDB | Unified WAL and memtable with full sync and no compression | Eligible | Awaiting campaign |
Remote durable commit on RustFS
Every eligible participant uses the same pinned RustFS image on loopback. A successful sample must include the engine's documented remote-durability barrier, not only submission or immediate visibility.
| Engine | Client path | Eligibility | Current result |
|---|---|---|---|
| Flyology.DB | Indexed flyology_object_storage=0.1.0-dev client | Eligible | Awaiting campaign |
| SlateDB | object_store AWS client with awaited durable writes and WAL enabled | Eligible | Awaiting campaign |
| TidesDB | Pinned TidesDB S3 path | Unsupported | Not ranked |
Why TidesDB is not ranked remotely: the pinned TidesDB implementation can ignore object-store WAL upload failures. A throughput number from that path would not represent the same durable outcome.
A result must carry its evidence.
The panel accepts a campaign only when the retained artifact names exact engine, adapter, compiler, build flags, dependency source, storage revision, workload, host, power profile, raw samples, errors, and checksum.
- Prove eligibilityRun the participant's maintained correctness gate before timing.
- Match the environmentMeasure every comparison on one host and one detectable power profile.
- Retain raw workKeep every repetition, elapsed time, byte count, error count, and state checksum.
- Validate the artifactReject unsupported cells, incomplete provenance, or summaries that do not match samples.
One durable mutation, measured the same way.
Each operation begins one transaction, writes one unique 16-byte key and 1,024-byte value, and waits for the lane's durable commit result. Creation and full close, reopen, read, and SHA-256 verification stay outside the timer.
- Writer geometry
- One writer, one mutation per transaction, one fresh database per repetition
- Timed region
- Begin, put, and durable commit
- Verification
- Close, reopen, read every key, and compare the same state checksum across participants
- Campaign geometry
- Warmup, operation count, and repetitions are retained inputs, never hidden defaults
Source identities stay visible.
The first campaign will resolve Flyology Object Storage from the Flyology Alire index without a Git or filesystem pin. Each result will record both the resolved source commit and the exact Alire-index commit.
- Flyology Object Storage
0.1.0-devresolved fresh from the Flyology Alire index; each campaign records its exact source and index commits- SlateDB
e0161973d8d7ffdede7c44725729838811674e99- TidesDB
23a67a6531bc6c0b537d3696758c7879586dcfce- RustFS
ghcr.io/rustfs/rustfs@sha256:800cf3f352a0a27e3275ca854a51f0027975d7acc7a0d52089a35bcc9fcbf0b5
Read the workload, contract, and validatorReview support boundaries