WAL (write-ahead log)

A write-ahead log (WAL) is an append-only file where a database records every change before it changes the data files themselves. A transaction counts as committed once its log record is safely on disk. After a crash, the database replays the log to rebuild any changes that had not yet reached the data files.

How it works

1. The database appends a record describing the change to the WAL.

2. It flushes that record to disk with fsync, then confirms the commit to the client.

3. Changed data pages stay in memory and are written later, at a checkpoint.

4. On restart, the database replays WAL records from the last checkpoint forward.

PostgreSQL stores WAL in 16 MB segment files by default. Replicas and change data capture tools read the same log to follow the primary.

Why it matters in production

The WAL is why a power cut does not lose committed data, and it is the stream behind replication and point-in-time recovery. It also costs disk. A replication slot whose reader has stalled keeps every segment it has not consumed. A primary that writes 2 GB of WAL per hour holds 48 GB after one stalled day.

See also

• Change data capture

• MongoDB oplog

• RTO and RPO

• Schema migration

• ACID transactions

• Key-value store

On the One2N blog

• How one parameter stalled Postgres replication with Debezium for 3 weeks

• Disaster recovery for SREs: the practical playbook for RTO, RPO, and cutover

Further reading

• PostgreSQL documentation: write-ahead logging