Thread

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

   Nikolay Samokhvalov <nik@postgres.ai> — 2026-05-21T14:20:34Z

   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
   

2. Re: Rename Postgres 19 to Postgres 26 (year-based)?

   Junwang Zhao <zhjwpku@gmail.com> — 2026-05-21T15:18:54Z

   On Thu, May 21, 2026 at 10:20 PM Nikolay Samokhvalov <nik@postgres.ai> 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.
   
   >
   > Nik
   
   
   
   -- 
   Regards
   Junwang Zhao
   
   
   
   

3. Re: Rename Postgres 19 to Postgres 26 (year-based)?

   Kirk Wolak <wolakk@gmail.com> — 2026-05-21T17:44:08Z

   On Thu, May 21, 2026 at 10:20 AM Nikolay Samokhvalov <nik@postgres.ai>
   wrote:
   
   > I was thinking:
   > ... 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
   >
   +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!
   

4. Re: Rename Postgres 19 to Postgres 26 (year-based)?

   Isaac Morland <isaac.morland@gmail.com> — 2026-05-21T18:45:43Z

   On Thu, 21 May 2026 at 13:44, Kirk Wolak <wolakk@gmail.com> wrote:
   
   
   >   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...
   >
   
   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.
   

5. Re: Rename Postgres 19 to Postgres 26 (year-based)?

   Tom Lane <tgl@sss.pgh.pa.us> — 2026-05-22T15:54:04Z

   Isaac Morland <isaac.morland@gmail.com> writes:
   > 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.
   
   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
   
   
   
   

6. Re: Rename Postgres 19 to Postgres 26 (year-based)?

   Peter Eisentraut <peter@eisentraut.org> — 2026-05-24T14:22:47Z

   On 22.05.26 08:54, Tom Lane wrote:
   > Isaac Morland <isaac.morland@gmail.com> writes:
   >> 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.
   > 
   > 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?
   
   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.
   
   
   
   
   

7. Re: Rename Postgres 19 to Postgres 26 (year-based)?

   Tom Lane <tgl@sss.pgh.pa.us> — 2026-05-24T17:03:59Z

   Peter Eisentraut <peter@eisentraut.org> writes:
   > On 22.05.26 08:54, Tom Lane wrote:
   >> 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?
   
   > 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.
   
   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
   
   
   
   

8. Re: Rename Postgres 19 to Postgres 26 (year-based)?

   Philip Alger <paalger0@gmail.com> — 2026-05-24T17:31:55Z

   > > On 22.05.26 08:54, Tom Lane wrote:
   > >> 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?
   >
   
   
   > 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.
   >
   
   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
   

9. Re: Rename Postgres 19 to Postgres 26 (year-based)?

   Nikolay Samokhvalov <nik@postgres.ai> — 2026-05-25T22:21:45Z

   On Sun, May 24, 2026 at 10:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
   
   > Peter Eisentraut <peter@eisentraut.org> writes:
   > > On 22.05.26 08:54, Tom Lane wrote:
   > >> 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?
   >
   > > 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.
   >
   > 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
   >
   
   
   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
   

10. Re: Rename Postgres 19 to Postgres 26 (year-based)?

    jian he <jian.universality@gmail.com> — 2026-05-25T23:28:06Z

    On Tue, May 26, 2026 at 6:22 AM Nikolay Samokhvalov <nik@postgres.ai> 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.
    >
    > 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
    >
    
    https://www.postgresql.org/docs/
    After "PDF Version", add another column makes sense to me.
    
    > https://www.postgresql.org/docs/release/
    > 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.