Tick fence

In one line: the per-tick durability boundary — at the end of each tick, dirty SingleVersion writes are batched into the WAL, so a crash loses at most the last tick.

SingleVersion writes are in-place and visible immediately, but not individually logged. The tick fence is where they become durable: dbe.WriteTickFence(n) batches every dirty SingleVersion slot since the last fence into WAL records, establishing a crash-recovery boundary — you lose at most the last tick, never a torn value. The same step applies deferred index / spatial / cluster maintenance. Under the runtime it runs automatically each tick; from a bare transaction you call it yourself after writing.

This is the sharpest case of Typhon's visible ≠ durable split: a SingleVersion value is visible the instant it's written, and becomes durable one fence later.

⚠️ "Tick fence" is overloaded — three meanings. Here it's the per-tick durability step. It is not a memory/CPU fence, and not the internal parallel-execution machinery that speeds that step up. The TickFence durability discipline is the transaction-time enum whose durability this step realises.

How it relates

• Tick — the fence runs at the end of every tick.
• Storage mode — only SingleVersion relies on the fence (Versioned is commit-durable; Transient never persists).
• Durability — mode & discipline — realises the default TickFence discipline (≤ 1 tick loss); the Commit discipline opts out for zero loss.
• WAL & checkpoint — the fence emits the WAL records that make the writes durable.

In the API

• DatabaseEngine — WriteTickFence(...) (called for you under the runtime).
• DurabilityDiscipline — TickFence (default) vs Commit.

Learn & use

• Narrative: Guide ch.3 — transactions & durability · ch.5 — the tick loop
• Reference: Isolation & durability cheat sheet
• Feature detail: TickFence discipline · parallel tick fence