PostgreSQL 18 incremental backups work, but only if summarize_wal was on beforehand

A walkthrough published on dev.to runs PostgreSQL 18's incremental pg_basebackup end to end: set the required parameters, take a full backup, change data, take an incremental against the full backup's manifest, then use pg_combinebackup to combine and restore ^[1]. The feature itself is unremarkable in operation; what it adds to a runbook is two preconditions that are easy to discover at the wrong moment.

The first is `summarize_wal`. It enables WAL summarization and is required for incremental backups ^[3]. In the walkthrough it goes into postgresql.conf alongside `wal_level = replica`, `archive_mode = on` and an `archive_command` that copies segments with `cp` ^[2], and the server is restarted before any backup is taken ^[4][2]. Treat that ordering as the requirement rather than as something to find out during your first incremental run.

The second is that `backup_manifest` becomes an operational input, not an archived artifact. The manifest is what identifies the contents of a backup when an incremental is created ^[7], and the incremental command points directly at it: `pg_basebackup -D /PGbackup/Incremental/ --incremental /PGbackup/Full/backup_manifest -P` ^[10]. The full backup directory listing shows that manifest at 138,089 bytes next to a complete data directory ^[6].

The scale numbers are worth reading carefully because they are demo scale. The full backup reported 23,648 of 23,648 kB across one tablespace ^[5]. Between backups the author created a database, a two-column table and inserted a single row ^[8], changes the full backup does not contain ^[9]. The incremental directory then lists a total of 252K, of which the new backup_manifest is 184K ^[12]. That is roughly 1 percent of the bytes the full backup moved ^[15], and about three quarters of the incremental is manifest ^[16]; the manifest also grew about 36 percent against the full backup's copy ^[20]. At real data volumes the ratio inverts, but the metadata floor is real.

One caution on instrumentation: the incremental run's progress line reads 11,477 of 31,360 kB (36%) ^[10], a denominator 7,712 kB larger than the full backup's total ^[17]. The source does not explain that, and the line is a mid-run snapshot, so incremental progress percentages are not a measure of delta size. The directory listing is. File timestamps put the two backups four minutes apart ^[13][14], which tells you nothing transferable about your own window.

The consequence for retention is the part to write down. Because the incremental contains only the data required to update the referenced backup ^[11], the referenced full backup and its manifest sit inside the restore path ^[18]. Expiring the full backup after a successful incremental leaves you with something that will not restore. And restore is no longer a copy of a data directory into place: it requires pg_combinebackup ^[1]. The excerpt available stops partway through the incremental directory listing, so verify the exact invocation and flags against the manual rather than against this walkthrough.

Watch three things: whether `summarize_wal` is already on in every PG18 cluster you own, what manifest size does relative to data as clusters grow ^[16], and whether your restore automation and your drills actually call pg_combinebackup ^[1].