Table of Contents

Durability — mode & discipline

In one line: two orthogonal dials decide when and how a committed change reaches disk. Keep them separate — conflating them is the classic Typhon confusion.

Durability is a different clock from visibility: a change becomes visible at Commit, and becomes durable when the WAL is flushed — which may be later. Two dials control the flush.

DurabilityMode — when the WAL flushes

Set per Unit of Work. Applies to every commit in that UoW.

Mode Flush Commit latency At risk on crash
Deferred only on explicit Flush() / FlushAsync() — dispose does not flush ~1–2 µs everything since last flush
GroupCommit automatically, ~every 5 ms ~1–2 µs ≤ one flush interval
Immediate fsync on every Commit ~15–85 µs nothing

Deferred and GroupCommit commit at the same speed and are visible before durable; only Immediate blocks Commit() until the change is on disk. A single critical transaction can escalate to Immediate — never downgrade.

CommitDiscipline — how a SingleVersion write is made durable

Set per transaction; applies only to the SingleVersion layout.

  • TickFence (default) — in-place, last-writer-wins, durable at the next tick fence (≤ 1 tick loss). Maximum throughput for hot, loss-tolerant data.
  • Commit — the write is staged, made atomic + zero-loss durable at Commit via a logical-redo WAL record, then published in place — read-committed isolation, O(1) rollback, no revision chain. For writes that must not be lost and must be all-or-nothing (teleport, item pickup) without paying for MVCC.

📌 The discipline (how) is orthogonal to the mode (when) and to the storage mode (layout). Commit discipline is what the feature catalog calls "Committed" — it is not a StorageMode value.

How it relates

In the API

Learn & use