WAL Generation and Write Amplification

Every change in PostgreSQL is first written to the Write-Ahead Log (WAL) before it touches the data files. WAL guarantees durability and crash recovery, but the bytes it produces are not free.

• Disk I/O: WAL is fsynced on commit, so high WAL volume means more write throughput pressure.
• Replication: every WAL byte must be shipped to replicas and read by logical decoders.
• Backups: archived WAL (via archive_command or pg_receivewal) grows storage and restore time.

This lesson is about measuring the WAL each transaction generates and reducing it without sacrificing durability.

WAL records are emitted for far more than just your row changes. Knowing the sources is the first step to cutting volume.

• Heap/index changes: inserts, updates, deletes, and the index entries they touch.
• Full Page Images (FPIs): the first write to a page after a checkpoint logs the entire 8 KB page, not just the change.
• HOT pruning and visibility map updates.
• Hint bit / freeze writes during VACUUM.

FPIs are usually the single biggest and most surprising contributor to write amplification.