Write-Ahead Logging (WAL)

What is write-ahead logging?

Write-Ahead Logging (WAL) is the technique that makes databases crash-safe: before any change is applied to the actual data pages, it’s first written to a sequential, durable log. The rule is in the name — the log entry goes to stable storage ahead of the data modification. If the database crashes mid-operation, recovery replays the log to reconstruct a consistent state. This is the beating heart of the D (durability) in ACID, and virtually every serious database — Postgres, MySQL, SQLite, and beyond — relies on it.

Why it’s fast and safe

WAL looks like extra work (write twice?) but is actually a performance win, because it converts random I/O into sequential I/O. Data pages are scattered across the disk; updating them in place means slow random writes on the critical path. WAL instead does one sequential append to the log (fast), acknowledges the commit, and lets the actual data pages be updated lazily in the background (checkpointing). So a transaction is durable the moment its log entry hits disk, not when every data page is updated — you get durability at sequential-write speed. This is the same insight LSM-trees exploit, applied to crash recovery.

What WAL enables beyond durability

The log isn’t just for recovery — it’s a stream of every change, which turns out to be enormously useful. Replication: ship the WAL to replicas and they replay it to stay in sync — this is literally how Postgres streaming replication works. Point-in-time recovery: archive the WAL and you can restore to any moment by replaying to a chosen log position. Change data capture: tools tail the WAL to stream database changes into other systems (event-driven pipelines, search indexes, caches). The humble recovery log became the backbone of modern data movement.

What people get wrong

• Ignoring checkpoint tuning — too-infrequent checkpoints make crash recovery slow; too-frequent ones add I/O; both show up as latency.
• WAL disk as an afterthought: since every commit waits on a WAL write, slow WAL storage caps your entire write throughput.
• Not archiving WAL and losing point-in-time recovery — then discovering it during the incident you needed it for.

Primary source: PostgreSQL documentation — Write-Ahead Logging