Rename Postgres 19 to Postgres 26 (year-based)?

First seen: 2026-05-21 14:20:34+00:00 · Messages: 10 · Participants: 8

Latest Update

2026-05-27 · claude-opus-4-6

Incremental Update: Proposer Pivots to Lightweight Alternatives

The most significant development is that Nikolay Samokhvalov has explicitly conceded the year-based versioning proposal and pivoted to two much lighter alternatives that don't require changing the version number at all.

Nikolay's Revised Proposal (Two Parts)

  1. Documentation enhancement: Add release year and EOL date inline on high-traffic docs pages (/docs/, /docs/release/, /docs/current/index.html) so operators don't have to navigate to the separate versioning policy page. This addresses the original "how old is this?" problem without touching version numbers.

  2. Parallel year label in marketing materials: Use formulations like "PostgreSQL 19 (2026)" in release announcements and press kits. The integer remains authoritative; the year is purely informational. If release slips, only the label changes. If cadence becomes biannual, extends naturally to "(2026.1)" / "(2026.2)".

Assessment

This is a graceful retreat that preserves the underlying user-experience goal while respecting all three objections raised by Tom Lane and Peter Eisentraut (slip risk, marketing-year ambiguity, cadence flexibility). The new proposals are purely presentational — no code changes, no server_version_num impact, no ecosystem disruption.

Jian He's response is minimal — a brief acknowledgment that adding a column to the docs page "makes sense" but uncertainty about placement on the other pages. No substantive technical debate has emerged around the revised proposals.

The thread appears to be winding down. The original versioning rename is effectively dead; the remaining question is whether the documentation/labeling suggestions gain traction with the docs or web team.

History (2 prior analyses)
2026-05-25 · claude-opus-4-6

Incremental Update: Core Committer Opposition Emerges

The most significant development since the initial analysis is that two core committers (Tom Lane and Peter Eisentraut) have now weighed in, both opposing the proposal. This effectively changes the trajectory of this thread from "positive but lightweight support" to "unlikely to proceed."

Key New Arguments Against

  1. Release schedule coupling risk (Tom Lane): The fundamental objection is that year-based versioning assumes a fixed annual release cadence. If "v2027" slips into 2028, the project faces an awkward choice: release with a "wrong" year number, or skip a version number entirely. Neither is acceptable.

  2. End-of-year marketing problem (Peter Eisentraut): Products released late in year N are often branded as N+1 for marketing reasons. This means year-based versioning doesn't actually eliminate ambiguity — it just creates a different kind of argument about whether to use the current year or next year.

  3. Future release cadence flexibility (Tom Lane, relaying PGConf.dev discussion): At the AI-focused unconference session at PGConf.dev, there was speculation that AI-accelerated development could eventually enable two major releases per year. While Tom Lane explicitly noted he doesn't necessarily believe this, it illustrates that tying version numbers to years constrains future flexibility in release scheduling.

  4. Perceived obsolescence problem (Pål Gerhard): A release occurring in December would appear outdated just weeks later when the calendar year changes, creating artificial pressure on users/enterprises to upgrade for optics rather than technical reasons.

Notable Context

Tom Lane's opening remark — "I thought we were permanently done with what-shall-we-call-the-next-release threads" — signals fatigue with versioning discussions among long-time contributors, suggesting low appetite for revisiting this settled decision.

2026-05-22 · claude-opus-4-6

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.