TL;DR
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
PostgreSQL 19 is expected later than the project’s recent release window, with November a likely target, according to a PostgreSQL developer’s report. The author links the delay and several late feature reversions to more bugs being found with large language models, while noting that fixes still require human review.
PostgreSQL 19 is likely to arrive in November 2026, later than the database project’s recent release window, as developers handle an unusually heavy flow of bug fixes and late feature removals. PostgreSQL developer Robert Haas attributes much of the increased bug discovery to people using large language models (LLMs) to find problems in the code, though the explanation is his assessment rather than an official project-wide finding.
Haas’s report says PostgreSQL major releases over the past decade have generally arrived between mid-September and mid-October. For version 19, he writes that a November release is likely and that a further postponement remains possible. The report does not give a confirmed release date or say that the project has formally announced a delay.
Several substantial features were removed late in the beta period: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE … MERGE PARTITION/SPLIT PARTITION. Haas says the reversions happened between August 27 and September 15, later than is typical for removing major features after the annual April 8 feature freeze.
Haas compares commit totals over the same period in consecutive years. From April 8 to September 25, 2026, PostgreSQL’s REL_19_STABLE branch received 1,169 commits, compared with 724 commits to REL_18_STABLE over the equivalent 2025 period. He says back-patched commits to the current stable branch rose by more than 60%. Commits to the prior stable branch also increased: REL_18_STABLE received 433 during the 2026 period, compared with 248 to REL_17_STABLE in 2025, a rise of more than 74% according to his calculation. These are commit counts, not direct counts of unique bugs or proof of their cause.
How AI Changes Release Work
The delay illustrates a tension for a widely used database project: tools that help identify defects can also add work before a release. Finding bugs faster does not automatically make them faster or safer to fix. Haas says LLM-generated fixes may be incorrect or fail to meet PostgreSQL’s standards, leaving human developers responsible for review and acceptance.
He also argues that attention diverted to bugs and security issues in older supported releases left less time to review changes intended for version 19. If that account is accurate, the release schedule reflects both a larger stream of reports and limited reviewer capacity. The project’s decision to remove features and delay shipping can be read as a quality-control response, not evidence by itself that the database is broadly unreliable.
The longer-term concern Haas raises is whether maintainers can keep pace as AI tools expose defects in mature code. That question extends beyond PostgreSQL: projects may have to balance faster defect discovery against the human effort required to verify fixes and keep development moving.
Popular right now

Dreame G10 Pro Wet and Dry Vacuum Mop

Ninja Crispi Glass Air Fryer (Stone) – 4‑in‑1

KitchenAid Artisan 5-Quart Tilt-Head Stand Mixer, Almond Cream
As an affiliate, we earn on qualifying purchases.
The Late Features and Fixes
PostgreSQL has a long development history, and Haas describes its code as large and complex, with a version-control history stretching back more than 30 years and earlier code predating that. He says bugs have always existed in software; what has changed, in his view, is how readily outside contributors can identify and report them with LLM assistance.
The release process includes a feature freeze, which Haas says takes place each year on April 8. Feature reversions can occur after that point, but he characterizes multiple major removals late in the beta period as unusual. The three named features were removed between late August and mid-September 2026, while maintainers were also handling fixes in the current and prior stable branches.
Haas’s commit comparisons show a distinction between development work on the main branch and fixes applied to supported releases. He says main-branch commits from the feature-freeze period through September 25 fell slightly year over year, while stable-branch back-patches rose sharply. The figures suggest increased maintenance activity, but they do not alone establish that LLM use caused the increase; that causal explanation is the author’s interpretation of reports and workload patterns.
Release Date and AI Evidence
No final release date is supplied in the report, and a November launch is described as likely rather than confirmed. It remains possible, according to Haas, that the project could postpone the release further.
The commit totals do not identify how many separate bugs were reported, how many were found with LLMs, or what share of the extra fixes resulted from AI-assisted reports. Haas presents LLM-driven discovery as the leading explanation, while acknowledging that increased mistakes by contributors could account for some of the change. The report also does not provide an official PostgreSQL project statement confirming that explanation or detailing the release decision.
What Maintainers Must Resolve
PostgreSQL developers still need to address outstanding issues, review proposed fixes, and decide when version 19 is ready to ship. The next clear milestone will be an official release schedule or a project announcement confirming the date; neither is included in Haas’s report.
For users planning upgrades, the practical step is to treat November as a forecast, not a commitment, and watch the project’s release communications. Haas says developers are working on how to respond to the greater volume of AI-assisted findings, but he does not describe a settled plan for handling that workload or its effects on future feature development.
Key Questions
When will PostgreSQL 19 be released?
No confirmed date is given. Robert Haas says a November 2026 release is likely and that a further delay is possible.
Why is PostgreSQL 19 late?
Haas attributes the delay to more bugs being found with the help of LLMs, alongside the human time needed to review fixes and address security issues and bugs in supported older releases. This is his explanation, not a formally confirmed project-wide finding.
Which features were removed from the release?
The report names UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE … MERGE PARTITION/SPLIT PARTITION. Haas says they were reverted between August 27 and September 15.
Do the commit figures prove AI caused the increase in fixes?
No. The figures show more commits to stable branches over the compared periods, but they are not counts of unique bugs and do not establish why the fixes increased. Haas interprets the rise as largely connected to LLM-assisted bug reports.
Does the delay mean PostgreSQL 19 is unsafe?
The report does not say that. Haas describes the delay as a quality-focused response to development and maintenance work; users should wait for the project’s release announcement and guidance before planning an upgrade.
Source: rhaas.blogspot.com
