Checkpoint

The point at which a database declares that everything logged before it is also on the data pages, so recovery never has to replay further back than that. It is the other half of write-ahead-logging: the log makes a crash survivable, and the checkpoint bounds how much of the log a survivor has to read.

PostgreSQL triggers one every checkpoint_timeout seconds (default 5 minutes) or when max_wal_size (default 1 GB) is about to be exceeded, whichever comes first.

It is a trade, and both sides are expensive

Checkpointing more often shortens crash recovery, because less work must be redone. It also costs more, in two distinct ways the engine documentation separates: every dirty buffer has to be written out, and the log gets bigger afterwards.

The second cost is the surprising one and it runs through full-page writes. The first modification of a page after a checkpoint logs the entire 8 kB page rather than the change, because a torn write leaves a page no delta can repair (postgres-wal-reliability). So a shorter checkpoint interval means each page pays its full-image toll more often, and the WAL volume rises. Fast recovery and a small log are in opposition, and the mechanism connecting them is the checkpoint.

Postgres paces the write rather than doing it in one burst — checkpoint_completion_target, default 0.9, spreads the dirty-buffer flush across 90% of the interval — which converts a latency spike into sustained background I/O.

Where it shows up elsewhere in this spoke

• Recovery time objectives. How far back a crashed primary must replay is a checkpoint question, not a WAL question.
• Backup and replication. pgbackrest and patroni both operate on WAL segments; the checkpoint determines which segments a base backup must be paired with.
• The bursty-latency complaint. The response-time bump after a checkpoint is a known enough effect that the docs recommend raising wal_buffers specifically to smooth it.

The same idea appears under other names in the analytical siblings and in log-structured stores, where compaction plays a comparable role — bounding how much accumulated log a reader must traverse. Nothing in this corpus yet states that comparison from a source; it is edge 6's LSM half.

Related

write-ahead-logging · postgres-wal-configuration · postgres-wal-reliability · postgresql · patroni · pgbackrest · operational-databases