Databases often keep the “real” data in memory or on pages that are slow to flush. That is fine until the process dies. A write-ahead log (WAL) is a durable diary: every change is appended to a file before the system pretends the change is committed.

Think of it as writing the shopping list on paper before rearranging the pantry. If you drop the jars, the list still says what you intended.

1. Append "set X = 7" to the log (fsync)
2. Update the in-memory / page version of X
3. Later, flush pages at leisure

On restart, replay the log from the last checkpoint and rebuild what did not make it to stable pages. That is why WAL is not the same idea as log-structured storage: one is a recovery journal; the other is a primary storage layout that also appends. Same append motion, different job.

The name to keep: append first, then apply. Implementations differ; the diary metaphor holds.