Write-ahead log

A write-ahead log ensures data integrity.

The idea is that changes to data files (i.e. your db tables) are only done after those changes have been logged.

This is really useful when you’ve got HA scenarios with multiple databases as trying to write data files sequentially is a pain whereas logs are always sequential so are easy to write.

WAL results in a significantly reduced number of disk writes, because only the log file needs to be flushed to disk to guarantee that a transaction is committed, rather than every data file changed by the transaction. The log file is written sequentially, and so the cost of syncing the log is much less than the cost of flushing the data pages. This is especially true for servers handling many small transactions touching different parts of the data store. Furthermore, when the server is processing many small concurrent transactions, one fsync of the log file may suffice to commit many transactions.

Note: this means journaled file systems are not necessary for reliable storage of the data files.

See: https://www.postgresql.org/docs/9.1/wal-intro.html

and

https://stackoverflow.com/questions/14181180/why-do-sql-databases-use-a-write-ahead-log-over-a-command-log