# The Write-Ahead Log (WAL) The Lazy Elephant has made a blood pact with you (otherwise known as the `ACID` guarantees). The most important part of this pact is **Durability**. Durability means if the elephant tells you "Yes, I successfully saved your new profile picture," and then immediately the power goes out, the server crashes, and the building burns down... when you boot up a new server from the scorched hard drive, your profile picture must still be there. How do you guarantee this? The obvious, naive way is: _Every time someone INSERTs a row, force the physical hard drive to synchronously write that entire Page down to the magnetic rust of the disk before responding "OK"._ Postgres refuses to do this. Remember the golden rule: **Random writes to a disk are exhausting.** Forcing the disk to spin, seek to the middle of `users.dat`, and write 8KB of data, thousands of times a second for every single tiny transaction, would bring the database to an absolute, grinding halt. ## The Frantic Diary So how does Postgres guarantee safety without doing the exhausting work of precisely updating the data files? It cheats. It uses the **Write-Ahead Log (WAL)**. Instead of carefully taking your new row and meticulously walking over to the filing cabinet (`DataFiles`) to slide it into the perfect alphabetical slot... the elephant just keeps a massive, linear journal sitting right on his desk. When you make a change, the elephant violently scrawls a highly compressed, sequential note at the very bottom of the journal: > _"Transaction 983 inserted ID:4 into Page 12 of Users."_ Appending data to the absolute end of a sequential file is the fastest, easiest, laziest disk operation in existence. There is no seeking. There is no searching. It is just a blind, raw `O(1)` dump of bytes to the end of a log. Because this log append is so cheap, Postgres can afford to enforce that **every single commit MUST immediately successfully flush to the WAL diary before it responds "OK" to the user.** Thus, the blood pact is secured. If the power goes out, Postgres can just wake up, look at its diary (the WAL), walk over to the filing cabinet, and manually replay all the frantic scribbles it hasn't actually filed yet. ## Checkpointing (Eventually doing the dishes) This is great for performance, but eventually, the dishes have to be done. You can't just write to a diary forever, or you'll run out of paper, and your actual filing cabinets (the `.dat` files we search during queries) will be totally out of date. Every 5 minutes or so, a background worker called the **Checkpointer** sighs heavily, gets out of its chair, and does the actual hard work. It looks at all the dirty pages sitting in memory that have only been backed up by the WAL diary, and meticulously, carefully flushes them all into their proper, random locations in the permanent data files. Once it finishes, it draws a massive red line in the WAL diary: a **Checkpoint**. This line means: _"Everything above this line in the diary has actually been permanently filed away. We can safely throw these pages of the diary in the trash."_ Doing the right thing means guaranteeing durability. Doing the least work possible means frantically scribbling in a diary today and making a background worker file the homework tomorrow.