The current release-build measurements on the documented Linux benchmark host put an accepted single-row write without fsync at 4.4828 microseconds and a durable commit at 4.6721 milliseconds. The three orders of magnitude between them are not a mystery in the storage engine. They are the storage device, filesystem, kernel, and controller agreeing that the log reached stable media.

What the WAL guarantees

A transaction stages row versions against the current database state, then commit serializes the authoritative change into the append-only write-ahead log. A commit acknowledged as durable has passed the WAL fsync. Recovery can replay committed log records that have not yet reached immutable sorted runs, while incomplete or uncommitted work does not become a visible transaction merely because some bytes were written.

The WAL is not the final table format. MongrelDB is log-structured: committed changes feed a Bε-tree memtable keyed by RowId and epoch, then flush into immutable .sr sorted runs using PAX-style columnar pages. Readers merge the mutable layers and runs under MVCC, so a snapshot sees the row version appropriate to its epoch while compaction and later writes continue.

That architecture keeps synchronous commit work narrow. It also makes maintenance part of the design rather than an optional cleanup script, because many small runs eventually cost more to merge at read time than one compacted run.

Group commit changes throughput, not physics

When multiple committers reach the durability boundary together, the engine can append their WAL records and share a storage flush instead of issuing one fsync per transaction. The device still has to make the bytes durable, but more useful work rides inside one barrier.

That is what group commit is for. It does not make fsync take microseconds on hardware where fsync takes milliseconds, and it does not turn an accepted pre-fsync write into a durable one. It amortizes the barrier across concurrent work.

The published one-million-row and write-path measurements include:

These are engineering measurements from one Intel Core Ultra 9 386H machine with local NVMe storage, not a promise that another filesystem, virtual disk, laptop power mode, or cloud volume will flush at the same latency.

Flush, compaction, and garbage collection

A durable WAL can recover data, but keeping every historical WAL segment forever would make startup and disk usage increasingly unpleasant. MongrelDB flushes mutable state to immutable sorted runs, compacts multiple runs into a new clean generation, persists the manifest swap, then lets garbage collection reclaim obsolete runs and stale WAL segments when pinned snapshots no longer need them.

The daemon checks for tables with enough accumulated runs and compacts them in the background. Short-lived embedded or CLI processes can close with an explicit flush and schedule periodic compaction. A compaction remains crash-safe by retaining the old run set until the new run is fsync’d and the manifest points at it.

This is the log-structured trade: writes stay append-friendly and scans stay column-friendly, while the engine spends background IO merging generations. If the process opens, writes a handful of rows, and exits thousands of times without flush or maintenance, the run and WAL shape will eventually tell you that the deployment ignored half the storage model.

Accepted is not durable

Applications should name their guarantees honestly. A telemetry buffer may accept a write and tolerate losing the final few milliseconds after power failure. A payment ledger may require each response to mean the WAL is durable. A bulk importer may stage a thousand rows and commit once because one barrier for the batch is both faster and easier to reason about than a thousand independently durable rows.

The API distinction lets the application choose that boundary instead of hiding it behind one overloaded word called save. The benchmark page uses the same language: accepted writes acknowledge before fsync, durable commits include fsync.

What to measure on your hardware

Start with the deployment filesystem and storage class, because an NVMe workstation, an encrypted laptop volume, a container overlay, and a network-attached cloud disk can have radically different barrier behavior. Measure p50 and p99 durable commit latency under the expected number of concurrent writers, then add readers, compaction, backup, and the largest analytical query the application will run.

MongrelDB’s mixed-load qualification makes the point. Four writers and four readers on a one-million-row workload recorded a 33.012 millisecond commit p50 and 176.885 millisecond p99 on the published host, far above the single-committer 4.6721 millisecond result because concurrency, snapshot retention, and shared resources changed the workload. Neither result invalidates the other; they answer different operational questions.

The runnable commands and machine details live in BENCHMARKS.md. If a durability number appears without its fsync policy, transaction size, concurrency, filesystem, and storage device, it is not a database result yet, it is a caption waiting for the rest of the experiment.