Full Page Write (FPW) is a durability mechanism in PostgreSQL that writes complete 8KB pages to the Write-Ahead Log (WAL) on the first modification of a page following a checkpoint. This technique serves as a critical safeguard against data corruption resulting from torn pages—incomplete or partially written pages that can occur when a database system crashes during a write operation before all page data has been persisted to disk.

FPW addresses a fundamental challenge in database durability: ensuring that partial writes do not corrupt the database state. When PostgreSQL modifies a page in the buffer pool, that modification must eventually be written to persistent storage. However, if a system crash occurs mid-write, only a portion of the 8KB page may be written to disk, leaving the page in an inconsistent state. On recovery, PostgreSQL cannot reliably determine whether a partially written page contains committed data or garbage.

By writing the entire page to WAL on first modification after a checkpoint, PostgreSQL creates a complete snapshot that can be used to restore the page to a consistent state during crash recovery ¹⁾. This approach guarantees data integrity without requiring additional disk I/O operations to verify page checksums during recovery.

The FPW process operates as follows: After a checkpoint completes, the first modification to any previously clean page triggers a full page write to WAL. This includes the entire 8KB page content, not just the modified bytes. Subsequent modifications to the same page within the same checkpoint cycle write only the logical changes (the actual byte modifications) to WAL, avoiding redundant full-page copies.

The mechanism depends on checkpoint boundaries to determine when full pages must be written. When a new checkpoint begins, the “full_page_writes” state resets, requiring the next modification to each page to generate a new full-page WAL record. This design balances safety with efficiency: full pages are written only once per checkpoint cycle, while hot pages that receive multiple modifications incur the overhead only once ²⁾.

While FPW provides critical durability guarantees, it introduces significant performance overhead in write-heavy workloads. The full-page copies substantially increase WAL volume, with reported inflation reaching up to 15x in applications with high write throughput. This inflation manifests as:

* Increased I/O overhead: WAL records containing full pages consume considerably more disk bandwidth and storage than logical change records * Buffer pool pressure: The larger WAL volume can stress the buffer management system * Network overhead: In systems with WAL streaming replication, the expanded WAL volume increases network traffic between primary and replicas * Checkpoint latency: More voluminous WAL can extend checkpoint operations

The severity of the performance impact depends on the ratio of modified bytes to page size. Small updates inflate WAL volume significantly more than bulk operations that modify many bytes per page. Write-heavy OLTP workloads with small transactions are particularly affected ³⁾.

Database administrators can disable FPW by setting `full_page_writes = off` in PostgreSQL configuration. However, this option is only safe when using storage systems that guarantee atomic page-aligned writes or when external mechanisms (such as filesystem journaling) prevent torn pages. Most production deployments keep FPW enabled to ensure safety across diverse storage hardware.

Alternative approaches to managing FPW overhead include:

* Optimizing checkpoint frequency: More frequent checkpoints reduce the period during which full-page writes are required, though they increase checkpoint overhead * Write coalescing: Batching small modifications into fewer, larger writes reduces the number of pages requiring full-page copies * Specialized storage backends: Some modern storage systems (such as those used in cloud database services) implement atomic page-level writes at the hardware level, enabling FPW to be safely disabled

The decision to disable FPW represents a fundamental trade-off between durability guarantees and write performance, requiring careful analysis of storage hardware capabilities and application-level crash resilience requirements.

Recent work in PostgreSQL optimization has explored techniques to reduce FPW overhead without compromising durability. These include incremental improvements to WAL compression, more granular checkpoint management, and integration with storage systems that provide atomic write guarantees. Cloud database services have adopted specialized approaches, such as decoupling the storage layer from the compute layer, to mitigate FPW performance penalties while maintaining full durability ⁴⁾.

• XLOG_FPW_CHANGE WAL Record
• Write-Ahead Log (WAL)
• Checkpoint Mechanism
• Compute-Layer WAL vs Storage-Layer Image Generation