Benchmarks

Every number on this page comes from a committed evidence run with zero errors in every row, and every harness ships in the repository. Two instruments are used on purpose: our own matrix harness, and warp, MinIO's own benchmark tool, so the comparison cannot hinge on whose ruler was used. Read the caveats before quoting anything; they are part of the result.

Large objects, 64 MiB (2026-06-11)

Two-system run (the reliable configuration: a four-system matrix fights for the same host), AWS SDK Go v2 driver, five iterations per row, sizes and concurrency as labeled. Throughput in MiB/s; ratio is Lockwell over MinIO; p50 latency in milliseconds.

Operation	Concurrency	Lockwell	MinIO	Ratio	Lockwell p50	MinIO p50
PUT	1	293	244	1.20x	219	267
PUT	16	1524	477	3.19x	647	1832
PUT	64	1622	590	2.75x	2406	6597
GET	1	2781	2018	1.38x	22	31
GET	16	13736	4659	2.95x	71	195
GET	64	5461	3546	1.54x	723	1120
multipart PUT	1	303	239	1.27x	206	264
multipart PUT	16	1050	589	1.78x	921	1551
multipart PUT	64	1287	579	2.22x	3166	6943
multipart COPY	16	3292	465	7.07x	296	1995
multipart COPY	64	2532	657	3.86x	1550	5833
mixed RW	16	98	47	2.09x	54	186
mixed RW	64	79	35	2.23x	642	1047

LIST and HEAD at 64 MiB: LIST 4.1x to 6.5x in Lockwell's favor across concurrencies; HEAD wins at c1 and c64 and loses narrowly at c16 (0.90x), a transport-bound small-operation path shared by both servers.

Cross-check with MinIO's own tool: warp 1.3.1 (2026-06-12)

warp put, warp get, and warp mixed, identical parameters against both servers on the same stack: 1 MiB objects, 16 concurrent clients, 20 seconds per operation. Zero errors on either side.

warp benchmark	Metric	Lockwell	MinIO	Ratio
put	MiB/s	2561	236	10.9x
get	MiB/s	6857	5454	1.3x
mixed: GET share	MiB/s	2628	1500	1.8x
mixed: PUT share	MiB/s	876	500	1.8x
mixed: STAT share	obj/s	1752	1000	1.8x
mixed: DELETE share	obj/s	585	333	1.8x

The 10.9x PUT figure deserves its own caveat: it is real and reproducible, and a large part of it is the durability tier described below, which warp's small-object PUT pattern amplifies.

Storage footprint

For the identical 44 GiB random (incompressible) write set of the 64 MiB run, measured with block-based du on both data volumes: Lockwell 44.0 GiB, MinIO 81.2 GiB (0.54x). Random data is the worst case for Lockwell's deduplication and compression; on a compressible, duplicated dataset in an earlier validated run (2026-06-04), Lockwell stored 5.15 MiB where MinIO stored 1015.9 MiB.

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.
• One host. Server and client share a machine (Docker Desktop). Ratios and p50s are the signal; absolute numbers will differ on your hardware, which is why the harnesses ship.
• MinIO version. Each run pulls minio/minio:latest at run time; the warp run used the image current on 2026-06-12. 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.
• Zero-error policy. A row with any failed request is discarded and the run repeated. Every row above had zero errors.

Reproduce

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 per-run evidence (transcripts, versions, raw outputs) under bench-results/. The methodology and the regression thresholds the release gates enforce live in docs/benchmark-baselines.md.