Write-Ahead Log (WAL)
TechniqueDatabase InternalsMidSeniorUpdated
Append every change to a sequential log and fsync before touching the data pages. On crash, replay the log to recover committed work.
When to Use Write-Ahead Log (WAL)
Durability is required and random page writes are too slow. Used by Postgres WAL, MySQL redo log, SQLite WAL mode, RocksDB WAL, Kafka log segments, and HDFS edits log.
In Practice
Postgres: a COMMIT is acknowledged once its WAL records are fsynced to
pg_wal/. Dirty data pages are flushed lazily at checkpoint. Replication streams the same WAL to standbys.How Write-Ahead Log (WAL) Comes Up in Interviews
Scenario
A Postgres benchmark shows 200k TPS with synchronous_commit = off, but only 20k TPS with the default. The team wants both durability and throughput. Best lever?
Group commit batches multiple transactions' WAL into one fsync. Faster storage (NVMe with battery-backed cache) helps too. Disabling fsync risks losing committed transactions on crash.
Cloud Postgres (RDS, Aurora) tunes group commit aggressively. Aurora goes further by writing to a distributed log layer that acks at 4-of-6 quorum instead of doing local fsync.