Postgres 19 Slipped Into November Because LLMs Keep Finding Old Bugs. Back-Patches to Supported Branches Are Up About 74%. Patch Your Minor Version This Week.
Robert Haas wrote on October 30 that Postgres 19 will most likely not ship until November, in a project whose major releases have landed between mid-September and mid-October. His explanation is that LLMs make old bugs much easier to find, while fixing them did not get proportionally easier. If you run Postgres by yourself, that has one immediate consequence and one slower one, and neither is about the new version.
What Haas actually reported
Three large features were reverted late in the beta period: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE ... MERGE PARTITION and SPLIT PARTITION. The reverts happened between August 27 and September 15. Feature freeze was April 8, and Haas notes that reverts shortly after freeze are normal, but several major ones this late are not.
His argument is that the codebase has a git history going back more than 30 years and code older than that, so the bugs were always there. What changed is the cost of finding them. People are running LLMs over the code and reporting what turns up, and each report needs a human to review the fix, because LLM-drafted patches are not always correct or compliant with project standards. Review time that would have gone into deciding what ships in 19 went into security issues and back-branch bugs instead.
The number that matters to you
Between April 8 and September 25, back-patched commits to the in-progress branch rose from 724 in 2025 to 1,169 in 2026, an increase of about 61%. Back-patched commits to the REL_17 and REL_18 stable branches in that window rose from 248 to 433, which is roughly three-quarters more.
Back-patching means fixes landing in versions people already run. That is the line I care about, because it is the line that reaches a solo operator. More fixes landing in the supported branches means more minor releases worth installing, and a wider gap between a server that stayed on its last minor version and one that did not.
Why a late release is not the news
I would not lose sleep over a Postgres major release arriving in November instead of October. Haas himself says he does not see the delay as especially concerning. The part he is unsure about is the long run: how the project handles decades of bugs that are now cheap to find, and whether it can keep adding features while every new one gets AI-assisted scrutiny.
For you that translates into a boring change of habit. If your upgrade routine is "pick a major version, run it for two years, touch it when something breaks," the supported branches are going to ask for more attention than that.
Where this could be wrong
Haas gives the cause as his reading, not a measured result. His post has no bug counts, only commit counts, and commit counts can rise for other reasons. His post also says commits to the master branch "declined slightly" while its own table shows 1,037 rising to 1,443, so I am not leaning on that claim and you should not either. The back-patch figures are internally consistent, and I trust them more than the narrative around them.
It is also possible the late release is mostly about three reverted features and a heavy review queue, with AI as one factor among several. I think the direction is right. I would not repeat the exact attribution as settled fact.
What I'd actually do
First, check your current minor version this week and install the latest one for your major branch. If you are on a managed provider such as Supabase, Neon or RDS, look at the provider's changelog and see how quickly it ships minors. That is the number I would track, not the date of Postgres 19.
Second, do not plan around the three reverted features. Haas does not say when or whether they return, so anything you wanted from them stays on the wish list for now.
Third, do not adopt 19.0 on day one. I treat the first release of a major version as a beta with a nicer name, and this year I have a specific reason to wait for 19.1 or 19.2. Put a calendar reminder on the first Tuesday of each month to check minors. It takes five minutes and it is the cheapest security work I know of.
Author
Lukas
@lukcombinator