Skip to content
ROOT
STUB

Write-Ahead Logging

The pattern: before mutating durable state, record the intent in a sequential log and fsync the log. On crash, replay the log to recover. Used by virtually every modern database for ACID durability, crash recovery, and replication.

The trade-off: durability latency vs. throughput. Sync log writes (full durability) are slow. Async (fast) risks losing recent writes on crash. Tunable knobs like Postgres synchronous_commit trade safety for speed. The log also doubles as a replication primitive — most replicated databases ship the WAL between leader and followers.

Deepens in Year 1 Phase 3 by watching Postgres WAL grow on disk and forcing checkpoints. Year 3 Phase 15 reinforces it by paralleling Iceberg snapshots inside basecamp’s lakehouse tier.

  • append-only-log — WAL is the durability special case of the general pattern.
  • snapshot-plus-delta — what bounds WAL replay time in production.
  • lsm-vs-btree — both index families lean on a WAL for durability.
  • replication — shipping the WAL is the canonical replication primitive.
  • consensus — replicated WALs (Raft, Paxos) are how distributed databases agree on a write order.