PostgreSQL 18 statistics do not finish the upgrade

An upgrade can start the new database successfully while leaving important acceptance work unfinished. PostgreSQL 18 reduces one source of disruption by retaining optimizer statistics during pg_upgrade. That improvement deserves to be used without treating it as proof that checksum settings, required rebuilds or application query behaviour have already been resolved. Plan the upgrade around a usable service, rather than the first successful server start.

Looking back from November 2026, PostgreSQL 18 was announced on 25 September 2025. The version 18 release notes give the same release date and list retained statistics among the main changes. These are stable-release facts. They differ from the earlier preview discussions about skip scan and generated columns, which concern choosing query and schema mechanisms rather than accepting an upgrade of an existing installation.

Statistics describe data distributions used when choosing plans. Carrying useful information across an upgrade can reduce the period in which the new server lacks that input. It does not freeze the optimizer or promise the same plan for every query. A new major release can make different decisions even when it starts with familiar statistical information.

The major-version 18 pg_upgrade manual, consulted in November 2026, says most optimizer statistics transfer unless --no-statistics is specified. It explicitly excludes statistics created with CREATE STATISTICS, extension-added custom statistics and cumulative-system statistics. This is maintained versioned documentation, not a frozen copy of the release-day page. The qualification prevents “statistics are retained” from becoming “all statistics survive unchanged.”

For an operating team, the distinction changes the post-upgrade schedule. There is less reason to assume every relation begins without ordinary optimizer statistics, but still a reason to follow the tool's instructions for missing information. Treat those instructions as part of the actual installation's output. A general article cannot determine which extensions or statistical objects your cluster contains.

A new-cluster default does not describe the old cluster

The release notes say initdb now enables data checksums by default. They also state that pg_upgrade requires matching checksum settings between clusters. An old cluster without checksums does not acquire them merely because the destination was initialized with PostgreSQL 18. The new default and the existing state are two separate facts that must be reconciled before the upgrade can proceed.

The same notes identify --no-data-checksums as an initialization option useful for a destination matching a non-checksum source. That is a documented compatibility option, not an instruction here to disable protection on a running database. The appropriate decision depends on the migration plan, verified source state and authorized operating procedure. No database settings or files were changed for this article.

This is also why an inventory should record state rather than only version numbers. Two installations running the same old major version can have different initialization histories. A plan copied from one can fail for the other even when both are otherwise healthy. Record what was observed about the source and what the destination must match, with an owner responsible for resolving discrepancies.

Required rebuilding belongs before acceptance

The pg_upgrade manual says it generates scripts for required post-upgrade processing and warns that accessing tables named in rebuild scripts before completion can produce incorrect results or poor performance. A server accepting connections therefore cannot be the only completion criterion. Read the installation-specific output and complete its obligations before treating affected data paths as ready.

The release notes give another scoped example: for clusters whose default non-libc collation provider behaves differently from libc for relevant character handling, reindexing indexes related to full-text search and pg_trgm after pg_upgrade is recommended. Preserve both the condition and the recommendation's strength. It is neither a universal obligation to rebuild every index nor permission to ignore an actual rebuild script.

File-transfer choices are a separate recovery decision. The version 18 manual warns that link mode can share files between old and new clusters; after the new cluster starts and writes them, the old cluster is unsafe to reuse without restoration from backup. Saving time in transfer does not establish an independent rollback copy. This article provides no migration commands and performs no transfer, database upgrade or recovery exercise.

Acceptance should follow important queries

A proposed acceptance set should include the queries customers or operators depend on, with representative parameters and data distributions. Check returned results as well as elapsed time and plans. A plan change is evidence to understand, not automatically a regression. A fast result with different business meaning is a failed acceptance even if the database reports no error.

Keep the comparison interpretable. Record source and destination versions, extensions, relevant configuration and whether the run represents a cold or warmed workload. Account for concurrent changes in the application. These are proposed checks for an authorized environment; no representative-query test, benchmark or downtime measurement was performed for this article. Retained statistics cannot supply those missing observations.

The strongest counterargument is a small database for which dump and restore is easier to understand and rehearse. That can be a sensible choice when its measured operating cost fits the business. The presence of a better pg_upgrade does not make it compulsory. For custom software development, choose the method with an explicit recovery path and acceptance evidence. Use retained statistics to reduce one disruption, then finish the compatibility and query work that makes the new service dependable.