PostgreSQL 14 goes unsupported a week before PostgreSQL 19 ships

Picture a team that pencilled "skip 18, go straight to 19 in November" into this quarter's plan. It sounded tidy in the spring. It doesn't work anymore. On 10 October, Jonathan Katz posted to pgsql-hackers that GA moves from 12 November to 19 November, with a second release candidate slotted for the 12th. And 12 November is already a loaded date: it's the scheduled quarterly minor release, and the versioning page lists it as PostgreSQL 14's final release.

So for one week, 14 is out of support and 19.0 isn't out at all. That's not a disaster. It's a scheduling fact you'd rather know now than on 13 November.

The dates, and the one page that hasn't caught up

Here's what the project's own pages say as of 18 October. RC1 came out on 15 October, as planned. The RC1 announcement gives RC2 on 12 November and GA on 19 November. Katz's list message says the release team made the call because of the volume of fixes landing in the back branches and a wish to keep shipping something stable, and it admits this has been "an atypical major release cycle". The versioning policy page gives PostgreSQL 14 (current minor 14.24) a final release date of 12 November 2026.

One page lags. The developer roadmap still lists PostgreSQL 19 as "October 2026". We'd trust the dated announcement and the list message over it, but if someone on your team reads the roadmap and books an October cutover, that's where the idea came from.

For context, 18 shipped on 25 September 2025 and 17 on 26 September 2024. A 19 November GA puts this release roughly eight weeks behind the usual late-September rhythm. The Register's headline says it "slips a month", which is fair if you count from the project's original autumn target. The last formal move, though, was a single week.

What got pulled before RC1

The Register reports that between eight and ten significant features were reverted this cycle. We went looking on the PostgreSQL 19 Open Items wiki page and in the commit log, and here's what we could confirm ourselves:

• SQL/PGQ property graph queries (GRAPH_TABLE, CREATE PROPERTY GRAPH). Reverted by Peter Eisentraut on 7 September, undoing about 50 commits across 125 files, including the pg_dump support.
• UPDATE/DELETE ... FOR PORTION OF, the temporal update syntax. Reverted by Eisentraut on 15 September, 23 commits and 71 files.
• pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl(). Reverted by Andrew Dunstan on 13 September; the open items entry reads "needs a redesign".

That's three features. We didn't find the other five or so in the places we checked, and we're not going to guess which ones The Register counted. What survived matters too: the RC1 notes list fixes for REPACK (CONCURRENTLY), pg_plan_advice, parallel autovacuum and COPY (query) TO ... (FORMAT json), so those are still in. If a migration script of yours leans on any of the reverted syntax, it'll fail on RC1 with a plain syntax error, which is at least easy to spot.

Now the part everyone's quoting. The Register has Eisentraut saying that with LLM-assisted code review, "these kinds of things can get found much faster", leaving maintainers with a list of forty defect reports. We can't verify the forty from the project's pages, and Katz's schedule message doesn't mention LLMs at all. Our read is that faster bug-finding probably helped push the reverts and the extra RC, but I might be wrong about how much. The official reason is the volume of back-branch fixes, full stop.

What we'd do this month

If you run 14 in production, don't wait for 19. Upgrade to 18, which has had a year of minor releases (it's at 18.6), and do it before 12 November if you can, so the last 14 minor release is a safety net rather than a deadline. pg_upgrade takes a 14 cluster to 18 in one step; run it with --check against a copy first, and read the 15, 16, 17 and 18 release notes for incompatibilities, because you're crossing four major versions at once. That's the boring answer. We think it's the right one.

If you're on 15 to 18, nothing forces your hand. Patch on 12 November: the RC1 announcement says that update release "will include a large number of fixes", which is unusually blunt for a minor release note. Put 19 RC1 on a staging box now, run your test suite against it, and file what breaks. That's the cheapest moment to report a regression.

And if you'd planned to run 19.0 in production on launch week, we'd still wait for 19.1. That was true before this cycle. After three late reverts and an extra release candidate, it's a bit more true. A recurring check on the versioning page is worth automating, too; our cron expression builder will spit out the line for a monthly reminder. We keep a similar calendar of announced retirements for AI models, and the lesson carries over: the end-of-life date is the one that bites.

FAQ

Sources: PostgreSQL, PostgreSQL 19 RC 1 Released (15 October 2026); Jonathan S. Katz, Updated PostgreSQL RC / GA dates, pgsql-hackers (10 October 2026); PostgreSQL, Versioning policy; PostgreSQL, Roadmap; PostgreSQL wiki, PostgreSQL 19 Open Items; commits 2b9e1aff4d3, a9d2f728240 and db169985c10; The Register, Postgres 19 delayed after AI reviewers find more bugs than humans can fix (16 October 2026).