TL;DR
Get the latest gadgets delivered free with Prime
- Fast, free delivery on millions of items
- Prime Video, Amazon Music and more included
- Member-only deals all year
PostgreSQL 19 is likely to ship in November, later than the project’s usual mid-September-to-mid-October window, according to PostgreSQL developer Robert Haas. Haas links the delay and several late feature reversions to a rise in bugs reported with help from large language models, while noting that the explanation is his assessment and that human review remains necessary.
PostgreSQL 19 is likely to arrive in November, later than the database project’s usual release window, after maintainers faced a heavy bug-fixing workload and reverted several major features late in the beta period. PostgreSQL developer Robert Haas attributes much of the increase in reported bugs to people using large language models (LLMs) to find defects, though the project has not announced a final release date in the material provided.
Haas’s report says PostgreSQL major releases have typically appeared between mid-September and mid-October over the past decade. For version 19, he expects a November release and says a further postponement is possible. The report does not provide an official revised schedule or a release-date announcement from the project.
Three substantial features were reverted between August 27 and September 15: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE … MERGE PARTITION/SPLIT PARTITION. Haas describes multiple major reversions this late in the beta period as unusual, while noting that reverts shortly after the annual April 8 feature freeze are not especially uncommon.
Commit counts cited in the report show more work going into stable branches. Between April 8 and September 25, 2026, PostgreSQL recorded 1,169 commits to REL_19_STABLE, compared with 724 commits to REL_18_STABLE during the same dates in 2025—an increase of more than 60%, according to Haas’s comparison. The master-branch count moved from 1,037 to 1,443 over those periods. For the previous stable release branch, counts rose from 248 commits to REL_17_STABLE in 2025 to 433 to REL_18_STABLE in 2026, an increase of more than 74%.
More Fixes, Longer Release Review
The delay illustrates a practical tension for a mature database project: tools that help identify defects can also increase the volume of work that maintainers must investigate, verify and fix. Finding a bug is not the same as resolving it safely. Haas says LLMs can draft fixes, but those suggestions may be incorrect or fail to meet PostgreSQL’s standards, leaving human developers responsible for review and approval.
Haas also says developer time that would otherwise have gone to reviewing PostgreSQL 19 changes was diverted to security issues and other bugs in older supported branches. That workload may affect both release readiness and decisions about which new features are safe to ship. For users, the immediate consequence described is a later release; the report does not identify a specific end-user vulnerability or say that PostgreSQL 19 is unsafe.
The broader concern is whether maintainers can keep pace as AI-assisted bug reports expose defects in decades-old code. Haas presents that as an open challenge for the project and software development more widely, not as a measured forecast of future release delays.
Products Worth Considering
Apple Watch SE 3 GPS 40mm Smartwatch
Amazon Kindle Scribe (64GB) with Premium Pen, Metallic Jade
Apple AirPods Pro 3 Wireless Earbuds with Active Noise Cancellation
As an affiliate, we earn on qualifying purchases.
How the Release Fell Behind
PostgreSQL follows an annual major-release cycle, with a feature freeze each year on April 8, according to Haas. After that point, developers focus on stabilizing the release rather than adding major features. Reverting a feature can still happen during this period, but the report says the timing and number of PostgreSQL 19’s late reversions stand out.
Haas’s comparison separates work on the development branch from fixes applied to stable releases. Master-branch commits between the freeze and September 25 were lower in 2026 than in 2025, he says, while commits to the relevant stable branches rose sharply. He interprets the difference as consistent with more bugs being discovered and fixed, including in older versions—not as proof that LLM use alone caused every additional commit.
The report first appeared on Haas’s blog and was also published by Neon. Haas argues that PostgreSQL’s long history and large codebase mean it has always contained defects, and that the new development is how much easier it has become for people to find and report them. He also says the findings do not change his view that PostgreSQL code is generally high quality.
PostgreSQL 19’s exact release date is not confirmed in the report, and Haas says a delay beyond November cannot be ruled out. The source material does not include a separate statement from the PostgreSQL project establishing a revised timetable or confirming the reasons for the delay.
The commit totals document more changes in stable branches, but do not count how many bugs were found with LLMs, how many reports came from AI-assisted work, or how many changes were security fixes. Haas’s explanation—that AI-assisted discovery accounts for much of the increase—is his interpretation. The material does not quantify the share of the added workload attributable to LLMs or provide independent evidence separating that effect from other causes.
It is also unclear how long the higher bug-report volume will persist, how it will affect future release schedules, or whether the project will change its review process in response. Haas describes those longer-term questions as unresolved.
Maintainers Continue Stabilization
The immediate next step is continued review, testing and bug fixing before the project sets or meets a release date. Haas’s account indicates that maintainers must assess which PostgreSQL 19 changes are ready to ship while also addressing issues in supported stable branches. The report does not name a next public milestone or give a date for another release-status update.
Users and organizations planning upgrades should rely on official PostgreSQL release announcements for the final schedule rather than treating November as confirmed. In the longer term, Haas says developers are working to understand how to handle the increased rate of bug discovery while continuing to maintain and develop the database.
Key Questions
When is PostgreSQL 19 expected to be released?
PostgreSQL developer Robert Haas expects it most likely in November 2026, but says a further delay is possible. The source material does not include a confirmed release date from the project.
Why does Haas think the release is late?
Haas links the delay to a heavier bug-fixing workload, including bugs he says are increasingly being found and reported with help from large language models. He also says work on older stable releases took time away from reviewing the upcoming release.
Which PostgreSQL 19 features were reverted?
The report names UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE … MERGE PARTITION/SPLIT PARTITION. It says they were reverted between August 27 and September 15.
Do the commit numbers prove LLMs caused the increase?
No. The counts show more commits to stable branches in the compared periods, but do not identify what caused each change or measure LLM-assisted reports. LLMs as a major cause is Haas’s assessment, not a conclusion established by the counts alone.
Does the delay mean PostgreSQL 19 is unsafe?
The report does not say that PostgreSQL 19 is unsafe or identify a specific security flaw in the release. Haas presents the delay as a consequence of additional bug fixing and review, reflecting the project’s attention to release quality.
Source: rhaas.blogspot.com
