A write-ahead log (WAL) is the technique a database uses to survive crashes without losing committed data. The rule is in the name: before any change is written to the main data files, a record describing that change is first written to a durable log. The PostgreSQL documentation states the central concept directly: “changes to data files (where tables and indexes reside) must be written only after those changes have been logged, that is, after WAL records describing the changes have been flushed to permanent storage.”
Logging first is what makes recovery possible. If the database crashes, any changes that had not yet reached the data pages can be reconstructed by replaying the log. PostgreSQL notes that because of this, “we do not need to flush data pages to disk on every transaction commit, because we know that in the event of a crash we will be able to recover the database using the log.” This is the mechanism behind the “D” - durability - in ACID, and it also improves performance, since sequential log writes are cheaper than scattered random writes to the data files.
SQLite offers WAL as an alternative to its older rollback journal. Its documentation explains that the original content stays in the database file while changes are appended to a separate WAL file, and “a COMMIT can happen without ever writing to the original database, which allows readers to continue operating from the original unaltered database while changes are simultaneously being committed into the WAL.” A periodic checkpoint later folds the logged changes back into the main file.
The canonical formal treatment of crash recovery via write-ahead logging is the ARIES method, published by C. Mohan and colleagues at IBM in 1992 as “ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging.” ARIES defined the redo and undo discipline that production database engines still follow, and IBM notes it was implemented in DB2 and other systems.