Write-Ahead Log
A write-ahead log records changes before they are applied to data files, giving durability and crash recovery and enabling replication.
Definition
A write-ahead log (WAL) is an append-only record of every change a database intends to make, written and flushed to durable storage before the corresponding data pages are modified. On crash, the log is replayed to recover committed transactions and roll back incomplete ones. The same ordered stream also powers replication and change data capture, because downstream systems can apply the log to reconstruct state.
Context and scope
The durability and recovery mechanism inside most relational and many NoSQL databases, and the source of logical replication streams.
Common misconceptions
- The WAL is the database backup — a backup plus the WAL enables point-in-time recovery, but the log alone is not a full copy
- WAL makes writes slower — it can be faster than in-place updates, because sequential log writes avoid scattered random I/O
- Any surviving log means no data loss — durability depends on the fsync policy; a log not flushed can still be lost
Anti-patterns
- Tuning fsync away for benchmark numbers, trading durability for speed without acknowledging the risk
- Letting the WAL grow unbounded because checkpoints or archiving are misconfigured, filling the disk
- Reading the physical log directly as a stable application API, which couples you to a file format
Related concepts
Related examples
Authoritative source
What it is
A write-ahead log is a durable, append-only sequence of records describing changes. The protocol is simple: before modifying a data page in place, write the change to the log and flush it. Because the log is written sequentially, flushing is fast, and because it is flushed first, a crash cannot leave a change half-applied. Recovery reads the log forward to redo committed work and undo transactions that never completed.
Why it matters
It is how databases promise durability without writing every change directly to scattered pages on disk. It also unifies three needs: crash recovery, replication, and change data capture. A replica applies the log stream to stay consistent; a downstream system consumes the same stream to build search indexes, caches, or warehouses without polling the tables. One ordered record serves all three.
How to use it well
Respect the fsync boundary: tune your durability setting knowingly, because disabling the flush trades committed data for speed. Keep checkpoints and archiving healthy so the log does not grow without bound or the disk fills. Use logical replication or a change data capture tool against the log rather than parsing physical files, so you are not coupled to an internal format. Monitor replication lag, since a growing lag on the log stream is an early warning for replicas and consumers alike.