Write-ahead log (WAL)
The database's crash-safety journal: record each change durably first, then apply it to the main data files.
See it
What it is
A write-ahead log records each database change in a durable, sequential log before the changed data pages are written to their normal files. After a crash, the database replays those records to recover committed work. It is the same principle a journaling filesystem such as ext4 uses. PostgreSQL calls the records WAL and stores active segments under pg_wal.
The same stream can feed replication and point-in-time recovery. Archiving WAL segments alongside base backups lets PostgreSQL replay changes up to a chosen recovery target, while streaming replication sends records to standby servers as they are produced.
Gotcha: WAL is not an audit trail and archived WAL is not a backup by itself. You still need a compatible base backup and a tested restore process. Broken archive commands or abandoned replication slots can also retain segments until the disk fills, so monitor archive failures, slot retention, and free space.
Ask AI for it
Configure PostgreSQL 16 WAL archiving for point-in-time recovery: set wal_level=replica, archive_mode=on, and an archive_command that copies each completed segment idempotently to a versioned Amazon S3 bucket. Create a pg_basebackup procedure, retain WAL for the stated recovery window, alert on pg_stat_archiver.failed_count, inactive replication slots, pg_wal growth, and low disk space, then document and execute a restore test using restore_command and recovery_target_time.