Rename Postgres 19 to Postgres 26 (Year-Based Versioning)

Core Problem

This thread proposes a fundamental change to PostgreSQL's versioning scheme: shifting from sequential integer major version numbers (currently approaching version 19) to year-based version numbers (starting with 26 for 2026). The proposal is motivated by a practical usability concern rather than a deep technical architecture issue — version numbers under the current scheme carry no inherent temporal information, making it difficult for operators managing heterogeneous PostgreSQL fleets to quickly assess how outdated a given installation is.

Context and Background

PostgreSQL's versioning history has already undergone one major transition:

• Pre-2017: Two-component major versions (e.g., 9.6 released in 2016, 9.5 in 2015)
• Post-2017: Single-integer major versions starting with 10 (2017), 11 (2018), etc.

The current scheme happens to have a convenient arithmetic relationship: version + 2007 = release_year (e.g., 10 + 2007 = 2017). However, this is not immediately obvious to users or non-technical stakeholders.

Proposed Solutions

Option A: Two-digit year (PG 26, PG 27, ...)

The original proposal from Nikolay Samokhvalov. This would skip versions 19-25, jumping directly from PG 18 to PG 26. The advantage is brevity and a natural continuation of the existing single/double-digit pattern. The disadvantage, noted by Isaac Morland, is potential ambiguity — in the distant future, people might not realize it was a deliberate renumbering rather than just skipping versions.

Option B: Four-digit year (PG 2026, PG 2027, ...)

Raised by Kirk Wolak as future-proofing. This eliminates any ambiguity about the versioning scheme and avoids the Y2100 problem where two-digit years would wrap. It also makes the scheme change unmistakably intentional — no one would think PG 2026 is 2008 releases after PG 18.

Precedents Cited

• macOS: Transitioned to year-based versioning (Version 26.x in 2025) combined with named releases (Tahoe, etc.)
• Ubuntu: Year.month versioning (e.g., 24.04) with codenames for LTS releases
• Debian: Sequential versions with codenames but no year-based numbering

Key Technical Implications

While this is primarily a project governance/branding decision rather than a code architecture change, it would have non-trivial technical ripple effects:

1. server_version_num: PostgreSQL uses a numeric representation internally (e.g., 180000 for PG 18). A jump to 260000 or 20260000 would affect all version-checking logic in extensions, drivers, and client tools.

2. PG_VERSION_NUM macro: Thousands of #if PG_VERSION_NUM >= XXXXXX guards exist in extension code across the ecosystem. Any scheme change must consider backward compatibility of version comparison logic.

3. pg_upgrade compatibility: Version ordering assumptions are baked into upgrade tooling.

4. Packaging and repository infrastructure: APT/YUM repositories, Docker tags, and CI matrices all encode version numbers.

5. Extension compatibility matrices: The PGXN ecosystem and tools like pgxman track per-major-version compatibility.

Assessment

This thread is an early-stage discussion/proposal with no patch attached and no engagement yet from core committers or the release management team. The responses are uniformly positive but come from community members rather than from those who would need to implement and manage such a transition. The thread does not address the substantial technical details of how the transition would be managed at the code level, in packaging, or in the broader ecosystem.

The proposal has merit from a user-experience perspective but would require significant coordination across the project's infrastructure, documentation, and the broader tool ecosystem to execute without causing confusion or breakage.