TL;DR
Get backup power and energy gear 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 now expected to arrive in November, later than the project’s usual mid-September to mid-October release window, according to PostgreSQL developer Robert Haas. Haas attributes the delay and several late feature reversions partly to more bugs being reported after people used large language models to find them; the commit counts he cites show a sharp rise in back-patched fixes, but do not by themselves establish the cause.
PostgreSQL 19 is likely to be released in November, later than the database project’s usual September-to-October schedule, as maintainers handle a heavier stream of bug fixes and several late feature reversions. PostgreSQL developer Robert Haas says the increase appears linked to people using large language models (LLMs) to identify defects, though the release date and the precise causes of the delay are not settled.
Haas wrote that PostgreSQL 19 “most likely won’t be released until November” and that a further postponement remains possible. His account describes the shift as unusual: over roughly the past decade, major PostgreSQL releases have generally arrived no earlier than mid-September and no later than mid-October. The project has not, in the material provided, announced a final release date.
Three sizeable 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 occurred between August 27 and September 15. Feature removals soon after the annual April 8 feature freeze are not especially unusual, he wrote, but having multiple major features pulled so late is less common.
Haas compared PostgreSQL commit counts over the same calendar window in 2025 and 2026. From April 8 through September 25, commits to the development branch rose from 1,037 to 1,443, while commits to the stable branch for the release in progress rose from 724 to 1,169. He also reported that commits to the previous stable release rose from 248 in 2025 to 433 in 2026. Haas characterizes the latter changes as back-patched fixes; the figures are commit totals, not a direct count of bugs or proof of why the totals changed.
More Bug Reports, Slower Release Work
The immediate impact for users and organizations planning upgrades is a longer wait for PostgreSQL 19 and uncertainty about its final contents. The late removal of major features also means teams should not assume that announced or developed functionality will ship in this release; the three named features were reverted, and the source does not say they will return before launch.
Haas’s explanation points to a capacity problem for maintainers, not simply a shortage of candidate fixes. LLMs can help produce code or identify suspicious behavior, but Haas says generated fixes still require review for correctness and compliance with PostgreSQL standards. Human review time is limited, and he argues that responding to bugs in older supported releases has competed with review work on version 19.
The broader concern is how software projects handle a larger flow of reports and potential defects. If more bugs are found in both new and older code, maintainers must decide how to validate fixes, prioritize releases, and continue feature development. Haas describes that long-term challenge as unresolved; the release delay itself, he says, is not particularly concerning and reflects the project’s focus on quality.
Products Worth Considering
Ring Alarm 14-Piece Wireless Security System Kit
Arlo Pro Wireless Security Camera, 2K HDR, 6th Generation, 4-Camera Kit
Shark Navigator Lift-Away Upright Vacuum, NV360
As an affiliate, we earn on qualifying purchases.
The Commit Counts Behind Haas’s Explanation
The source for the account is a blog post by Haas, originally published on the Neon blog and also presented at rhaas.blogspot.com. Haas is a PostgreSQL developer and is writing from his perspective on the project’s development work. His explanation should be understood as an informed account, not as a formal project statement establishing that LLM use is the sole cause of the delay.
The comparison covers commits made between April 8 and September 25 in each of two years. The development-branch total was lower in 2026 than 2025 only in the sense that the reported count did not rise in proportion to the stable-branch counts; Haas says it declined slightly. By contrast, the stable branch for the release in progress recorded 1,169 commits in 2026 against 724 in 2025, and the prior stable branch recorded 433 against 248. These are raw totals over the stated periods. They indicate more commit activity in those branches, but cannot on their own show how many defects were found, how severe they were, or whether LLM-assisted reports caused the increase.
Haas’s proposed mechanism is that more people online are reporting PostgreSQL bugs they found with LLMs. He says developers have been busy fixing those reports, including in older release branches. He also notes that software has always contained defects and describes PostgreSQL as a large codebase with a long history. In his view, the newer change is that some defects have become easier to discover, while the work of validating and integrating fixes has not become easier to the same extent.
Release Date and AI’s Exact Role
November is an expectation, not a confirmed launch date, and Haas says a later release cannot be ruled out. The source does not provide a project-approved schedule, a list of remaining release blockers, or criteria for deciding when PostgreSQL 19 is ready to ship.
The role of LLMs is also an explanation advanced by Haas rather than a demonstrated cause in the commit data. The totals do not distinguish AI-assisted reports from other bug reports, routine maintenance, or unrelated code changes. Haas allows that committers could have made more mistakes in 2026, although he says he does not think that is the main reason for the higher back-patch activity. The source does not quantify how many reports came from LLM use or how many fixes resulted from them.
It is also unclear whether any of the three reverted features could be restored, or whether they will be reconsidered for a later PostgreSQL version. Haas raises a longer-term question about how maintainers can keep up with defects found across decades of code while continuing to develop new features, but says he does not yet know the answer.
Maintainers Must Set the Release Threshold
The next concrete milestone is a release decision from the PostgreSQL project. Based on Haas’s account, maintainers still need to review fixes, determine which changes are appropriate for the release, and settle what remains in PostgreSQL 19 before publishing it. No specific date or further release milestone is given in the source.
Users and organizations preparing upgrades should follow official PostgreSQL project announcements for the final schedule and release notes. Those materials will establish the shipped feature set and any changes to the expected timing. In the meantime, Haas says developers are working to address the increased flow of bug reports and to understand how AI-assisted discovery may change maintenance work.
Key Questions
When is PostgreSQL 19 expected to be released?
PostgreSQL developer Robert Haas says the release will most likely arrive in November 2026, but he says a further delay is possible. The source does not give a confirmed release date.
Why does Haas say PostgreSQL 19 is late?
Haas links the delay to a heavier workload from bugs reported after people used large language models to find them. He says maintainers must review fixes themselves and that work on older release branches has also taken time from release review. The source does not establish LLMs as the sole cause.
Which PostgreSQL 19 features were reverted?
Haas names UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE … MERGE PARTITION/SPLIT PARTITION. He says they were reverted between August 27 and September 15; the source does not say whether they will return in a later release.
Do the commit totals prove that AI caused the delay?
No. Haas’s figures show more commits to the stable branches during the specified April 8-to-September 25 periods, but they do not identify which changes came from AI-assisted bug reports or establish the cause of the higher totals. The AI explanation is Haas’s assessment.
Should users be concerned about the delay?
Haas says he does not consider the delay particularly concerning and views it as a consequence of work to protect release quality. Users should wait for the project’s official announcement for the final date and release contents.
Source: rhaas.blogspot.com
