wal_compression

Definition PG 18 manual

This parameter enables compression of WAL using the specified compression method. When enabled, the PostgreSQL server compresses full page images written to WAL (e.g. when full_page_writes is on, during a base backup, etc.). A compressed page image will be decompressed during WAL replay. The supported methods are pglz, lz4 (if PostgreSQL was compiled with --with-lz4) and zstd (if PostgreSQL was compiled with --with-zstd). The value on is a historical spelling of pglz. The default value is off. Only superusers and users with the appropriate SET privilege can change this setting.

Enabling compression can reduce the WAL volume without increasing the risk of unrecoverable data corruption, but at the cost of some extra CPU spent on the compression during WAL logging and on the decompression during WAL replay.

How it works

Compresses full-page writes written in WAL file with specified method. A superuser or a role granted SET privilege can change it for the relevant session or configuration scope.

Compression applies to full-page images produced by full_page_writes, backup, or hint logging, not to every WAL record. pglz is built in; lz4/zstd availability depends on the build, and replay pays decompression CPU in exchange for lower WAL volume.

Monitor and change wal_compression together with full_page_writes, wal_log_hints, wal_level. Validate on the relevant server role and real workload, then use its superuser context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Expecting compression to affect every WAL record rather than full-page images.

Selecting lz4 or zstd on a server build that does not provide that method.

Ignoring compression CPU on the primary and decompression CPU during replay.

Changing a privileged session value and assuming other sessions or future connections inherited it.

Comparing WAL bytes without controlling checkpoint frequency and full_page_writes activity.

Workload guidance

OLAP: Provision WAL, archive bandwidth, and recovery I/O for bulk-load peaks. Coordinate load pacing and checkpoints when reducing spikes; never break the recovery chain for throughput.

OLTP: Establish durability and recovery objectives first, then tune wal_compression from WAL rate, flush latency, checkpoints, and peak pg_wal usage. Validate every change with crash/recovery and archive monitoring.

SMALL: Start from safe defaults and set explicit alerts for limited disk capacity. Do not disable durability or break the recovery chain merely to save modest I/O.