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

From: Nikolay Samokhvalov <[email-masked]>
Date: Thu, 21 May 2026 07:20:34 -0700

I was thinking:

in my mind, Postgres 9.6 was associated with 2016, and "6" at the end of
both the version and the year always helped me memorize the release year.

Memorizing is important when you deal with many databases running different
versions of Postgres – this gives you perspective how old the version is.

And over last 10 years, the release cycle is pretty stable, one major
version per year. So if the upcoming version were 26 instead of 19, and
next year's were 27, it would be easier to understand how current this
version is.

Nik

---

From: Junwang Zhao <[email-masked]>
Date: Thu, 21 May 2026 23:18:54 +0800

On Thu, May 21, 2026 at 10:20 PM Nikolay Samokhvalov <[email-masked]> wrote:
>
> I was thinking:
>
> in my mind, Postgres 9.6 was associated with 2016, and "6" at the end of both the version and the year always helped me memorize the release year.
>
> Memorizing is important when you deal with many databases running different versions of Postgres – this gives you perspective how old the version is.
>
> And over last 10 years, the release cycle is pretty stable, one major version per year. So if the upcoming version were 26 instead of 19, and next year's were 27, it would be easier to understand how current this version is.

Interesting. I think macOS has gone through a similar evolution, macOS
Tahoe (Version 26.5), released in May 2025. We could also give each
major release a name, which sounds pretty interesting to me.

Ubuntu uses a year-based versioning scheme and gives each LTS release
a name, while Debian does not use year-based versions but still
assigns a name to every release.

-- 
Regards
Junwang Zhao

---

From: Kirk Wolak <[email-masked]>
Date: Thu, 21 May 2026 13:44:08 -0400

On Thu, May 21, 2026 at 10:20 AM Nikolay Samokhvalov <[email-masked]>
wrote:

> I was thinking:
> ... And over last 10 years, the release cycle is pretty stable, one major
+1

  There are many reasons I like this.  First, it becomes obvious to
EVERYONE how far behind you are in the update cycles.
Right now, if you say you are on PG 12 or PG 17 most non-technical people
have no idea how far behind you are.

  From my perspective, I like management asking "It's 2032...  Why are we
on PG 28 still?"

  The only question it raises is if it should be PG 2026?   because in
about 1,000 years it could get confusing.
And I know the PG crowd likes to think ahead...

Kirk Out!

---

From: Isaac Morland <[email-masked]>
Date: Thu, 21 May 2026 14:45:43 -0400

> And I know the PG crowd likes to think ahead...

I like this because it makes it very clear that there has been a change in
numbering scheme. Skipping 7 numbers could be due to almost anything, in
the long term, but no one will think PG2026 is just 2008 versions after
PG18. Also, I agree that while most likely no one on this list will be
worrying about this in 2100, it would be nice to know that nobody has to
worry about what comes after PG99.

---

From: Tom Lane <[email-masked]>
Date: Fri, 22 May 2026 08:54:04 -0700

> worry about what comes after PG99.

Geez, I thought we were permanently done with what-shall-we-call-
the-next-release threads after we dropped three-part version numbers.

I don't like either version of this proposal, because I fear it
puts way too much faith in our ability to adhere to a fixed release
calendar.  What happens if "v2027" slips into 2028?  Are we then
unable to resume the normal schedule for the following release?

			regards, tom lane

---

From: Peter Eisentraut <[email-masked]>
Date: Sun, 24 May 2026 16:22:47 +0200

> unable to resume the normal schedule for the following release?

Furthermore, some things that release toward the end of year N are 
released as version N+1, for marketing reasons.  So this approach 
wouldn't even really reduce ambiguity or the need for more arguing.

---

From: Tom Lane <[email-masked]>
Date: Sun, 24 May 2026 13:03:59 -0400

> wouldn't even really reduce ambiguity or the need for more arguing.

A different angle came up in the AI-focused unconference session at
PGConf.dev: somebody speculated that use of AI might accelerate our
development cycle to the point where it'd be sensible to have two
major releases per year.  I'm not saying I believe that, mind you.
But it reinforces the point that tying our release numbers to years
would put undesirable constraints on our release calendar.

			regards, tom lane

---

From: Philip Alger <[email-masked]>
Date: Sun, 24 May 2026 12:31:55 -0500

> major releases per year.

Not only these points, but if a release occurs in December, the version
will seem outdated once the new year arrives in ~31 days. Users or
enterprises will feel compelled, or pressured, to upgrade because the name
will appear ancient to their clients if they are using v2025, for example.
-1 on using the year.

-- 
Best,
Phil Alger
EDB: https://www.enterprisedb.com

---

From: Nikolay Samokhvalov <[email-masked]>
Date: Mon, 25 May 2026 15:21:45 -0700

> would put undesirable constraints on our release calendar.

Understood. Thank you both for the direct responses.

The slip risk, the N+1 marketing-renumbering precedent, and the possibility
that cadence may change (biannual or otherwise) -- all make sense.

Year-tied version numbers don't fit. Let me propose something smaller that
still addresses the underlying user problem — knowing at a glance how old a
release is and when it goes EOL.

I have another, much lighter proposal. In fact, two paths:

1) Docs. Add something like "Major version NN released YYYY, EOL Mon YYYY"
explicitly on pages like:

https://www.postgresql.org/docs/
https://www.postgresql.org/docs/release/
https://www.postgresql.org/docs/current/index.html

Today, anyone reasoning about a Postgres version's age has to navigate to
https://www.postgresql.org/support/versioning/ and read the table.
Operators, support engineers, and vendors documenting compatibility do this
constantly. Putting the two dates inline on the docs landing pages removes
that lookup.

2) Annual-release label, alongside the version number. In release
announcements, news posts, and the press kit:

PostgreSQL 19 (2026)

and where prose flows naturally: "PostgreSQL 19, the 2026 annual major
release."

This doesn't tie the version to the year; the integer is still
authoritative. If slippage occurs, it only adjusts the label, and if the
cadence shifts to biannual, it naturally extends to "(2026.1)" / "(2026.2)"
without touching the version number. It's a parallel naming, not a
replacement.

Nik

---

From: jian he <[email-masked]>
Date: Tue, 26 May 2026 07:28:06 +0800

On Tue, May 26, 2026 at 6:22 AM Nikolay Samokhvalov <[email-masked]> wrote:
>
> The slip risk, the N+1 marketing-renumbering precedent, and the possibility that cadence may change (biannual or otherwise) -- all make sense.
>
> Year-tied version numbers don't fit. Let me propose something smaller that still addresses the underlying user problem — knowing at a glance how old a release is and when it goes EOL.
>
> 1) Docs. Add something like "Major version NN released YYYY, EOL Mon YYYY" explicitly on pages like:
>

https://www.postgresql.org/docs/
After "PDF Version", add another column makes sense to me.

> https://www.postgresql.org/docs/current/index.html
For these two links, I'm not entirely sure where the best place to put
that information would be.