Write-Ahead Log
A write-ahead log records changes durably before related data pages may reach permanent storage.
Jul 11, 2026
A Write-Ahead Log (WAL) enforces an ordering rule: log records describing a change must reach durable storage before a data page containing that change can be written to its durable location.
At commit, an engine can flush the transaction’s required log records without flushing every changed data page. After a crash, recovery replays logged changes that were committed but had not reached the data files. This roll-forward process is commonly called redo.
Checkpoints
A checkpoint establishes a recovery position by ensuring that required earlier changes are represented in data files and recording the point from which redo can begin. Checkpoints bound recovery work and allow old log segments to be recycled, subject to replication, backup, and archival requirements.
More frequent checkpoints can reduce recovery time but increase page-write pressure. Less frequent checkpoints retain more log and may lengthen recovery.
WAL Is Not Generic Undo
“Write-ahead log” describes ordering, not one universal record format.
PostgreSQL primarily uses WAL for redo and stores row versions in table storage. InnoDB has a redo log for crash recovery and separate undo logs for transaction rollback and reconstructing older versions for MVCC reads. It is therefore misleading to claim that every WAL contains both generic REDO and UNDO records.
Durability Boundary
A commit is only as durable as the engine’s configured flush behavior and the storage stack’s guarantees. Settings that acknowledge before the log is durably flushed can trade durability for latency. Replication also has its own acknowledgement boundary; a local commit does not automatically mean another node has persisted the change.
See Durability for the application-level guarantee.