What Is Write-Ahead Logging? The Note a Database Takes Before It Acts
Computers fail at the worst possible moments. A database is partway through updating a record when the power dies, the process crashes, or the machine simply stops. The operation was neither fully done nor cleanly undone, and the data is left in some unknown, half-finished state. The central question for any serious database is what happens next, and write-ahead logging is the answer most of them have settled on.
The idea is captured in the name, and it's almost startlingly simple: before the database makes a change, it first writes down what it's about to do. The note comes before the action. That ordering, log first, act second, is the whole principle, and it turns out to be enough to guarantee that a database can always recover from a crash without losing or corrupting data.
To see why the ordering matters so much, picture what a database is actually doing when it changes data. The real data lives in a structured form, often spread across pages on disk and cached in memory, and updating it properly can involve several steps: modifying the record, updating indexes, adjusting related structures. If a crash interrupts that sequence partway through, you're left with some of the steps done and some not, which is exactly the corrupted, inconsistent state you wanted to avoid. The change wasn't atomic; it got cut in half.
Write-ahead logging sidesteps this by separating the record of the change from the change itself. Before touching the actual data, the database appends a description of the intended change to a log: a simple, sequential file that just records, in order, what operations are being performed. Only once that log entry is safely written does the database go and apply the change to the real data. The log is the database's promise, written down in advance, of what it's going to do.
The reason this works comes down to a single guarantee about the log entry. Appending to a log is a simple, fast operation, far simpler than the multi-step update to the real data structures. Because it's simple and sequential, the database can ensure the log entry is fully and safely on durable storage before it proceeds. The log entry either made it to disk completely or it didn't, with no half-finished middle, and that all-or-nothing quality of the log is what the whole scheme rests on.
Now consider the two ways a crash can strike, because the log handles both. Suppose the crash happens after the log entry was written but before the change was fully applied to the data. When the database restarts, it reads through the log, finds the entry describing a change that was promised, checks whether that change actually made it into the data, and if not, applies it. This is called redo: the database replays the logged operations to complete the work it had promised but not finished. The change isn't lost, because the log remembered it.
Now suppose the crash happens before the log entry was safely written. In that case, from the database's point of view, the change never officially happened. There's no log entry promising it, so on restart there's nothing to replay, and the half-applied change, if any, gets treated as incomplete and rolled back. Either the change is in the log and gets completed, or it isn't and gets discarded. There's no middle outcome where the data ends up partially and permanently corrupted, and that clean either/or is exactly what the database needs.
This is why the discipline is sometimes summed up as a rule: never change the data before you've logged your intention to change it. If the database ever applied a change before logging it, a crash in that gap would leave a modification with no record, no way to know on restart whether it was complete, and no way to recover cleanly. The strict ordering, log first, always, is what closes that gap. The log is written ahead of the action, which is precisely what "write-ahead" means.
The approach brings a performance benefit that isn't obvious at first, and it's a large part of why databases embrace it rather than merely tolerate it. Writing to the log is fast because it's a simple sequential append, while updating the actual data structures in their final form is slower and more scattered. By committing the change to the quick log first, the database can tell the user the change is safely recorded almost immediately, then apply it to the main data more leisurely in the background. The log makes the change durable right away; the slower work of organizing the real data can follow at its own pace. Durability comes fast, and the expensive part gets deferred without any risk to safety.
The log can't grow forever, of course, and managing its size introduces a familiar piece of bookkeeping. Periodically the database confirms that all the changes up to a certain point have been fully and properly applied to the real data, which means the log entries describing them are no longer needed for recovery. This confirmation is called a checkpoint, and after one, the old log entries can be cleared away, keeping the log from expanding without bound. A checkpoint is essentially the database saying "everything up to here is safely settled; I no longer need the notes for it."
It's worth recognizing how widespread and foundational this idea is, because it tends to be invisible to anyone using a database. The major relational databases rely on write-ahead logging, and the same principle, log the intention before performing the action, shows up throughout computing wherever durability and crash recovery matter, including in file systems, where it's often called journaling. The names differ, but the move is always the same: record what you're about to do before you do it, so that an interruption can never leave you in an unrecoverable state.
The deeper lesson write-ahead logging teaches is that reliability often comes not from preventing failure but from making failure survivable. A database can't stop the power from dying mid-operation. What it can do is arrange things so that whenever the lights come back on, there's always a clear, recorded answer to the question of what was supposed to happen, and a clean way to either finish it or discard it. The note the database takes before it acts is what makes that answer possible. Write it down first, and a crash becomes a recoverable inconvenience rather than a catastrophe.