# Benchmarks

The promoted public matrix is **`20260810T105308Z-f3fd294`**. It ran on the project's Oracle Ampere A1 ARM64 host and
contains 51 rows each for Lockwell, MinIO, Garage, and SeaweedFS, zero request errors, and five completed
repair/scrub/backup/restore drills. Its generated competitive gate has **20 failures**, so the promoted evidence does
not support a performance-leadership or provider-replacement claim. The immutable manifest, hashes, raw rows, profile,
and gate are in `benchmark-baselines/phase1/`.

The latest complete unchanged-policy diagnostic is `bench-results/20260815T-full-access-log-23194cf`, bound to merged
`23194cf2dcbc93bad904d1743d82c365f9b4fe4d`; it reduced the generated gate to **10 failed checks out of 142** with the
same four targets and five drills, but it is not committed or promoted. Until a reviewed run is promoted, the tracked
baseline above remains the public release ledger and B-001 remains active.

The explorer below is the historical Lockwell-vs-MinIO presentation dataset. It remains useful for navigating operation,
size, concurrency, throughput, and latency dimensions, but it is not the current four-target release ledger. Read the
[caveats](#caveats) before quoting anything; they are part of the result.

::: tip How to read latency Throughput (MiB/s, ops/s) is "how much per second": **higher is better**. The p50 and p95
views are **response times in milliseconds**: p50 is the median request, p95 the slow tail, and **lower is better**. A
Lockwell p50 at half of MinIO's means Lockwell answers twice as fast. The Advantage column already does this arithmetic
for you, in the right direction, on every view. :::

## The ledger

<BenchmarksExplorer />

## Caveats

These are part of the result, not footnotes to hide.

- **Durability tier.** The bench configuration runs Lockwell in its grouped-durability tier (the write-ahead log is
  fsynced every 10 ms, not per commit, matching Garage's model; a power loss can cost up to ~10 ms of acknowledged
  writes). MinIO runs its defaults, which sync per operation. Lockwell's default tier is strict per-commit sync; if your
  threat model requires it, benchmark that tier instead. This asymmetry flatters Lockwell most on small-object PUT,
  which is exactly where the warp gap is largest.
- **Current host.** The promoted four-target baseline ran server and client containers on one Oracle Ampere A1 ARM64
  host (four cores, about 24 GiB RAM). Absolute results are host- and image-specific; the complete profile ships so the
  matrix can be rerun rather than generalized to unrelated hardware.
- **MinIO version.** Each run pulls `minio/minio:latest` at run time. Version-to-version variance is real, so cross-run
  comparisons of old tables mix that in.
- **CPU.** Lockwell sustains the higher throughput while using more CPU than MinIO at peak. It trades compute for
  throughput and disk; if you are CPU-bound, weigh that.
- **Failed rows remain visible.** The promoted baseline records 20 local-leadership failures across GET, HEAD, LIST,
  mixed-RW, multipart PUT, and PUT; the latest complete diagnostic records 10. `BLOCKERS.md` lists the exact tuples,
  and the generated gate remains authoritative for each artifact. Neither result clears B-001.
- **Storage.** Core throughput runs disable compression, deduplication, and encryption for an apples-to-apples engine
  comparison. Feature-profile storage-efficiency results are separate and must not be substituted for the core matrix.

## Neutral hardware

Dev-machine numbers carry dev-machine noise. The standing plan is to run the same two harnesses on a fresh low-cost
cloud box (the EUR 5 Hetzner class Lockwell is designed to fit), where nothing else is running, the exact specs are
public, and anyone can rent the identical machine and check.
[`scripts/bench-remote-hetzner.sh`](https://github.com/RusticStack/lockwell/blob/main/scripts/bench-remote-hetzner.sh)
provisions the server with `hcloud`, runs `make bench` and `make bench-warp`, copies the evidence back, and destroys the
box; the dataset selector above grows a new entry whenever such a run lands.

## Reproduce

```sh
make bench         # the full matrix harness (Lockwell, MinIO, Garage, SeaweedFS)
make bench-warp    # MinIO's warp against Lockwell and MinIO on the same stack
```

Both write raw per-run evidence under ignored `bench-results/`. Promote a completed matrix with
`go run scripts/promote-benchmark-baseline.go ...`; only its validated allowlist is committed under
`benchmark-baselines/phase1/`. The historical explorer is regenerated with
`node website/scripts/build-bench-data.mjs <matrix-dir> <warp-dir>`. The methodology and regression thresholds live in
[docs/benchmark-baselines.md](https://github.com/RusticStack/lockwell/blob/main/docs/benchmark-baselines.md).