A PostgreSQL upgrade is not simply a version change to postpone until a feature is needed. Minor releases, such as 16.4, arrive roughly quarterly and fix bugs, security issues, and data-corruption problems without adding features or changing internal formats. Avoiding them is considered riskier than applying them. Major releases add vetted features and may change the internal format of system tables and data files, so their existing data must be upgraded rather than used directly by the new server. section 7.6 section 7.8
The tempting mistake is treating an apparently stable database as safer when left untouched. Latent bugs, changing workloads, newly discovered vulnerabilities, and unsupported dependency libraries can all invalidate that assumption. PostgreSQL major versions are typically supported for five years; delaying them also defers features and enhancements, while failing to upgrade the operating system or libraries can create obscure performance problems, bugs, and vulnerabilities. section 7.6 section 7.8
Plan upgrades as a prepared operational change rather than a maintenance-window gamble:
- Apply minor releases regularly to receive fixes for bugs, security problems, and possible data corruption. section 7.6
- Read release notes across every skipped version, even when the upgrade path itself is reliable. section 10.1
- Test an upgrade or migration thoroughly before production; mistakes can cause performance issues, outages, or data corruption. section 10.0
- Use a staging environment that mirrors production, then roll out the tested change with time to spare. section 11.2
A smooth 13-to-16 upgrade can still change results
A PostgreSQL 13-to-16 upgrade using pg_upgrade finishes within a short maintenance window, yet a loyalty-discount calculation begins granting an extra month. The code adds 0.333 years to an expiry date. Testing the expression reveals a different resulting date after the upgrade because interval input with fractional units larger than months changed its rounding behavior. The upgrade procedure was successful; the unreviewed behavioral change in a release note was the defect. section 10.1
IF existing AND fullyear THEN
expiry = expiry + '0.333 years';
END IF;
Inspect the original date-arithmetic expression that turns a fractional year into a subscription extension; it is small enough to look harmless but depends on interval interpretation. section 10.1
Backward compatibility is generally strong: old PostgreSQL SQL will usually continue to work on current releases, and skipping a few versions can be reliable when the gap is not extreme. That reliability does not remove the need to examine release notes and run representative application tests. Upgrade safety comes from well-tested tooling, documentation, preparation, and verification of behavior that matters to the application. section 7.6 section 10.1
