The PostgreSQL 19 release date is now set for November 19, 2026, roughly a month later than the project expected in September. Release Candidate 1 shipped on October 15, a second candidate is scheduled for November 12, and somewhere between eight and ten significant features were pulled out of the release along the way. One cause stands out because it is new: LLM-assisted code review surfaced defects faster than maintainers could fix them. If you run Postgres in production, and especially if you are still on PostgreSQL 14, your upgrade calendar just got tighter.
What happened to the PostgreSQL 19 release date
When Beta 4 came out on September 24, the project still expected a release candidate in early October and said general availability might follow that same month. That didn't happen. RC1 arrived on October 15, and the PostgreSQL Global Development Group announced November 19 as the planned GA date.
The schedule also gained an extra step. According to the RC1 announcement, the November 12 update release for supported versions will include a large number of fixes, and the release team wants those in 19 before it goes GA. So RC2 ships on the same day as that update release. The announcement is careful with its wording: November 19 holds unless testing uncovers an issue that requires another delay or another candidate.
| Milestone | Date (2026) |
|---|---|
| Feature freeze | April 8 |
| Beta 1 | June 4 |
| Beta 2 | July 16 |
| Beta 3 | August 13 |
| Beta 4 | September 24 |
| RC1 | October 15 |
| RC2 | November 12 |
| Planned GA | November 19 |
Why AI-assisted review slowed the release
Reverting a feature late in a cycle is not unusual for Postgres. In an October 9 blog post, committer Peter Eisentraut wrote that roughly one revert per cycle is normal. This time he counts about eight to ten significant features, depending on how you count, with some pulled quite late in beta.
His explanation is the part every engineering lead should read. Alongside the serious problems there was a long tail of fairly harmless edge-case bugs. In earlier cycles, many of those would have appeared gradually and been fixed over the following five years. With LLM-assisted review they all showed up at once, and he describes looking at a list of around forty defect reports. Even when the average fix is only a few lines, each report carries a fixed cost: reproducing it, discussing it, reviewing the patch, committing it. Multiply that by forty and the beta window is gone.
He lists other factors too: some features had significant architectural defects, the system's complexity makes certain features very hard to get right, and from April to August many senior developers were busy fixing security issues, which reduced the usual review and testing during beta.
Eisentraut is also clear that this was not caused by vibe coding. Most of the reverted features were written long before LLM review was this useful, so the effective quality bar went up after the code had already been committed. The project's Beta 4 notes give the principle behind the decision: PostgreSQL must be reliable first.
There is a knock-on effect. The Register reports that the reverted features move to next year's PostgreSQL 20, and Eisentraut himself had said a few months earlier that 20 might contain no new features, only bug fixes.
What's in PostgreSQL 19 and what isn't
Reverted, so not in 19:
- SQL/PGQ property graph queries
- Online enabling and disabling of data checksums
- Temporal updates and deletes with the
FOR PORTION OFclause ALTER TABLE ... MERGE PARTITIONSandSPLIT PARTITIONSGROUP BY ALL(reverted in July, before Beta 3)
Still in 19, among the headline items Eisentraut lists:
REPACK CONCURRENTLY- Logical replication of sequences, a feature that was itself reverted once before
- Planner hinting with
pg_plan_advice
If your roadmap assumed graph queries in SQL or partition merge/split for large time-series tables, take them out of your 19 plans. PostgreSQL 20 is the likely home for them, but "likely" is not a commitment you should build a deadline on.
Compatibility changes to test
The official release notes include several changes that can break an upgrade or a restore:
- A warning is now issued after successful MD5 password authentication. Treat this as your prompt to move roles to SCRAM.
- Dumps made with pre-19
pg_dumporpg_dumpallwhilestandard_conforming_strings = offwill not load properly into 19. pg_upgraderefuses clusters whose database, role or tablespace names contain carriage return or line feed characters.- The default index opclass for
inetandcidrchanges from btree_gist to GiST, andpg_upgraderefuses clusters that have btree_gistinet/cidrindexes.
A few quick checks you can run on your current cluster today:
-- Roles still using MD5 password hashes (needs superuser)
SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';
-- Names that would block pg_upgrade (CR or LF)
SELECT datname FROM pg_database WHERE datname ~ '[\r\n]';
SELECT rolname FROM pg_roles WHERE rolname ~ '[\r\n]';
SELECT spcname FROM pg_tablespace WHERE spcname ~ '[\r\n]';
-- Run where your dumps are produced
SHOW standard_conforming_strings;
On managed services where pg_authid isn't readable, use the provider's tooling to audit authentication methods instead.
Three dates in one week: PG14 end of life, RC2 and GA
The calendar is what makes this news urgent. The official site says PostgreSQL 14 stops receiving fixes on November 12, 2026, the same day RC2 ships and one week before the planned GA. Under the project's versioning policy, each major version gets five years of support, then a final minor release, and then it is end-of-life.
That removes "just wait for 19" as an option for PG14 users. Even if GA lands on schedule, jumping onto a brand-new major version a week after your current one loses support is not a responsible production plan.
If you run on Azure Database for PostgreSQL
Microsoft's supported-versions page lists 18 as the newest version on flexible server, with 18.6 as the current minor. Microsoft has not announced when PostgreSQL 19 will be available. Its documentation also says servers on unsupported versions are automatically enrolled in extended support, that charges apply once any grace period ends, and that extended support should be treated as a temporary bridge. Microsoft also notes that certain extensions aren't supported on PostgreSQL 18, so check the extension list before choosing it as your target. Check the exact dates for your own servers in Microsoft's documentation and the portal rather than relying on secondhand timelines.
What teams should do now
Still on PostgreSQL 14
Upgrade now, and target 17 or 18 rather than 19. A practical sequence:
- Inventory extensions and confirm they are available on the target version.
- Rehearse the upgrade in staging with production-sized data, using
pg_upgradeor logical replication depending on your downtime budget. - Run the compatibility checks above and your full application test suite.
- Schedule the cutover with a rollback plan.
On 15 to 18 and interested in 19
If REPACK CONCURRENTLY or pg_plan_advice solves a real problem for you, spin up RC1 in staging now. Restore realistic data, run the compatibility checks, benchmark your heaviest queries and repeat on RC2, since it carries a large batch of fixes. Move production after the first minor releases, not on GA day.
Roadmaps that depended on reverted features
Replan with what exists today: application-level graph traversal, manual partition maintenance, explicit valid-from and valid-to columns. Revisit when PostgreSQL 20 is in beta.
The lesson for your own team: budget for fixing, not finding
The Postgres story isn't really about Postgres. Any team that adds LLM-assisted review or fuzzing to an existing codebase will hit the same wall: detection scales instantly, but triage and fixing don't. Eisentraut's own recommendation is that LLM-assisted fuzzing should become part of feature development, because it finds edge cases nobody could list by hand.
How to apply that in your own team:
- Run it early. Point AI review at feature branches during development, not at the release branch two weeks before launch.
- Plan triage capacity. Every finding has fixed overhead. Budget engineer time for it the way you budget for code review.
- Expect a spike on legacy code. The first pass over older modules will produce a backlog. Schedule a cleanup sprint instead of letting it collide with a release.
- Keep reverts cheap. Feature flags and small, isolated merges let you pull a feature without derailing the whole release, which is exactly what Postgres did.
A delayed release that ships with fewer known bugs is the system working. The mistake would be adopting the tools without changing the process around them.
Key takeaways
- PostgreSQL 19 GA is planned for November 19, 2026, with RC2 on November 12; the date depends on RC testing.
- About eight to ten significant features were reverted, including SQL/PGQ, partition MERGE/SPLIT and
FOR PORTION OF; they will likely move to PostgreSQL 20. - PostgreSQL 14 stops receiving fixes on November 12; upgrade to 17 or 18 now instead of waiting for 19.
- Test 19 in staging, check MD5 auth, dump settings and CR/LF names, and move production after the first minor releases.
- If you adopt AI-assisted review, plan capacity for fixing what it finds and run it early in development.