A PostgreSQL page modified for the first time after a checkpoint can generate much more WAL than a later modification to the same page. With full_page_writes enabled, the first protected change records a full page image so crash recovery can reconstruct a page even if an operating-system failure interrupts a physical page write.
That protection creates a recurring WAL pattern tied to checkpoint boundaries. A checkpoint resets the condition for pages, and subsequent writes gradually encounter pages that need a new full page image.
Full page images protect against torn page writes
PostgreSQL normally records changes in WAL before the corresponding data-file changes reach durable storage. Recovery can replay those records after a crash.
A physical data-page write introduces another failure boundary. Storage can receive only part of a page before power loss or an operating-system crash. The resulting on-disk page can contain a mixture of old and new bytes. A logical or row-level WAL record may not contain enough information to reconstruct a page whose prior structure is no longer reliable.
With full_page_writes enabled, PostgreSQL records the complete page content in WAL during the first modification of that page after a checkpoint. Recovery can restore that image and then apply later WAL records for the page.
The setting is enabled by default. Disabling it removes this protection and can permit unrecoverable or silent corruption after a system-level failure.
The checkpoint establishes a new protection interval
Crash recovery begins from a checkpoint-derived redo position. Data changes preceding the checkpoint are guaranteed to have reached the database files as required by checkpoint processing.
That boundary makes one full page image per modified page sufficient for the following checkpoint interval. Once WAL contains a usable image for a page, later changes in the same interval can generally rely on smaller change records. The next checkpoint begins a new interval, so the first protected modification of that page can require another image.
The cost therefore follows page access, not transaction count alone. Ten updates to one page can have a different WAL profile from ten updates spread across ten pages. The latter pattern can trigger full page images for more distinct pages after a checkpoint.
WAL generation can rise immediately after a checkpoint
A write-heavy workload often touches many distinct heap and index pages. Shortly after a checkpoint, a large fraction of those pages may be seeing their first modification in the new interval.
Those modifications can carry full page images, increasing WAL bytes per unit of application work. As the interval progresses, frequently modified pages have already paid that cost. Later changes to the same pages can produce smaller WAL records until another checkpoint resets the cycle.
This effect can make WAL throughput uneven even when the application write rate is comparatively stable. The variation is a property of page-level protection and checkpoint timing rather than necessarily a change in request volume.
Index activity participates as well. Full-page protection applies to database pages that require WAL safety, so a transaction that changes a heap tuple and several index pages can encounter multiple first-after-checkpoint page modifications.
Frequent checkpoints increase repeated page-image work
A shorter checkpoint interval gives pages less time to accumulate multiple modifications behind a single full page image. Hot pages can require another image sooner because each checkpoint starts another protection interval.
PostgreSQL documentation explicitly connects more frequent checkpoints with increased WAL output when full_page_writes is active. Checkpoint frequency is influenced by settings including checkpoint_timeout and max_wal_size, as well as workload WAL generation.
This creates a feedback path in busy systems. High WAL generation can contribute to checkpoint pressure, while frequent checkpoints can increase the rate at which full page images recur. The actual effect depends on the working set, page reuse, checkpoint triggers, and storage behavior.
Increasing checkpoint intervals can reduce repeated full-page-image overhead, but it also changes recovery and storage tradeoffs. A larger interval can leave more WAL to process during crash recovery and can increase the WAL space needed between checkpoints.
Page reuse determines the size of the effect
The number of distinct pages modified in each checkpoint interval is a major factor in full-page-image volume.
A workload concentrated on a compact hot set can modify the same pages many times. Each page generally incurs the full-page-image cost on its first protected modification, then subsequent changes reuse the protection already present in WAL for that interval.
A broad write workload can touch a much larger set of pages once or only a few times. In that case, a larger fraction of modifications can coincide with first-after-checkpoint access, making full page images a larger component of total WAL.
This distinction also separates row counts from physical write shape. Similar numbers of inserted, updated, or deleted rows can generate different WAL volumes when their page locality differs.
WAL compression changes bytes, not the protection boundary
PostgreSQL can compress full page images through wal_compression. Compression can reduce the WAL bytes consumed by those images, with CPU cost for compression during logging and decompression during replay.
Compression does not remove the checkpoint-cycle rule. A page that requires a full page image still crosses that protection boundary; the representation stored in WAL is simply compressed when the configured method can do so.
The resulting savings depend on page contents. Pages with compressible structure can shrink substantially, while less compressible data leaves less room for reduction.
Hint-bit logging can extend full-page-image activity
wal_log_hints causes PostgreSQL to WAL-log full page content for the first post-checkpoint modification involving otherwise non-critical hint-bit changes. Data checksums also require WAL protection for hint-bit updates, making the separate setting ineffective for that case.
This matters because page changes are not limited to application-visible row mutations. Internal page-state updates can contribute to WAL behavior when the durability configuration requires them to be protected.
The same checkpoint boundary still applies: the relevant first modification can carry the page image, and later protected changes to that page within the interval can proceed without repeating that image solely for the same checkpoint cycle.
WAL spikes can be a checkpoint signature
A rise in WAL volume after checkpoints can be consistent with normal full-page-write behavior. The signal becomes stronger when application write throughput remains stable while WAL bytes show a repeating relationship with checkpoint events.
The mechanism is physical and page-scoped. Checkpoints create fresh protection intervals, first modifications can log complete page images, and later modifications can use smaller records until the next checkpoint. Workloads that touch many distinct pages expose the effect more strongly than workloads that repeatedly modify a compact page set.
That relationship makes checkpoint frequency, page locality, and full-page-image volume part of the same WAL capacity model. Treating WAL rate as a direct proxy for application write rate can miss this periodic storage-level cost.