PostgreSQL Versioning Scheme: Numbering Semantics, 5-Year Lifecycle Model, and Zero-Downtime Patching

▸1. PostgreSQL Versioning Evolution: Pre-v10 vs Post-v10

With the landmark release of PostgreSQL 10 in 2017, the PostgreSQL Global Development Group modernized and simplified its versioning scheme:

Epoch	Major Version Representation	Minor Version Representation	Historical Example
PostgreSQL 9.6 & Earlier	First two numbers (`X.Y`)	Third digit (`Z`)	`9.6` was the major release; `9.6.1` and `9.6.2` were minor bugfixes. Moving from `9.5` to `9.6` was a major upgrade.
PostgreSQL 10 & Later	Single integer (`X`)	Second integer (`Y`)	`16` or `17` is the major release; `17.1`, `17.2` are minor maintenance updates.

[!IMPORTANT] There is no longer a concept of a "point major release" (like 17.1 being a major upgrade). 17 is major; 17.1 is strictly a bugfix/security patch.

▸2. The Annual Major Release Train

PostgreSQL operates on one of the most reliable, disciplined engineering cadences in open-source software:

1CommitFest Cycles (July - March): Five two-month development sprints.
2Feature Freeze (April): Code base frozen; no new feature patches accepted.
3Beta Releases (May - August): Public beta builds for community testing.
4Release Candidates - RC (August / September): Final regression testing and bug sweeps.
5General Availability - GA (September / October): Final major release dropped globally (16.0, 17.0).

▸3. Minor Releases: Why pg_upgrade is Never Required

Minor releases are published quarterly (February, May, August, November) or out-of-band for critical zero-day CVEs:

•Binary Compatibility: Minor updates within a major family never alter on-disk heap files, page layouts, index physical structures, or system catalogs.
•No Dump or Upgrade Utility Needed: You never run pg_dump or pg_upgrade to move from 17.1 to 17.2.
•Deployment Pattern:

bash

  # Debian / Ubuntu package upgrade:
  sudo apt-get update && sudo apt-get --only-upgrade install postgresql-17
  sudo systemctl restart postgresql

▸4. 5-Year Lifecycle & EOL Policy

The PostgreSQL project enforces an unambiguous support lifespan:

•Support Duration: Exactly 5 years of active maintenance from the initial GA date.
•The November Rule: Support officially lapses on the second Thursday of November in the 5th year.
•Post-EOL Exposure: Once retired, no security patches or CVE mitigations will ever be issued by the community.

sql

-- Query engine version and internal integer representation:
SELECT version();
SHOW server_version_num; -- e.g., 170001 (17.1)

▸5. Major Upgrade Strategies

Strategy	Downtime Window	Storage Footprint	Complexity	Senior DBA Verdict
`pg_upgrade --link`	1-5 Minutes	Negligible (Hard-links)	Low	Production standard for standalone/HA clusters.
`Logical Replication`	0 - 5 Seconds	2x (Parallel cluster)	Medium/High	Zero-downtime tier-1 fintech/e-commerce.
`pg_dump / pg_restore`	Hours to Days	High	Very Low	Suitable only for non-critical datasets < 50 GB.