Why A Log First
Updating a data page in place is risky: a crash mid write leaves a torn page. The write ahead log, or WAL, fixes this by recording the intended change to a durable append only log before the data page is modified. The rule is simple: the log record reaches disk first.
Recovery By Replay
After a crash the database does not know which pages were flushed. It runs recovery over the log:
- Redo reapplies every logged change from the last checkpoint forward, even ones already on disk, so no committed work is lost.
- Undo rolls back changes from transactions that never committed, so no partial work survives.
A checkpoint periodically marks how far the log has been safely applied, bounding how much must be replayed.
Why It Is Safe
Because the log is the source of truth, replay is idempotent: applying a redo record twice lands on the same state. That is what lets recovery rerun confidently after a crash during recovery itself.
Key idea
The write ahead log records intent durably before data pages change, so crash recovery can redo committed work and undo uncommitted work to rebuild a consistent database.