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 arrive in November, later than the project’s usual September-to-October release 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 humans still need to review fixes.
PostgreSQL 19 is likely to be released in November, later than the project’s typical mid-September to mid-October window, as developers contend with a rise in bugs reported with help from large language models, PostgreSQL developer Robert Haas wrote. He said the extra work has also contributed to several major features being removed late in the beta period, though the release date has not been finalized.
Haas compared commit activity between April 8 and September 25 in 2025 and 2026. In the 2026 period, PostgreSQL’s master branch received 1,443 commits, compared with 1,037 in the same period a year earlier. The current stable branch, REL_19_STABLE, received 1,169 commits, up from 724 to REL_18_STABLE in 2025 — a rise of more than 60%, according to his figures.
Haas also pointed to increased maintenance work on an older supported release: REL_18_STABLE had 433 commits during the 2026 period, compared with 248 to REL_17_STABLE during the corresponding 2025 period. He attributed the larger backport workload to more people reporting PostgreSQL bugs they found using LLMs. The figures count commits; they do not, by themselves, establish how many distinct bugs were found or what tools were used for each report.
Three major 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 said multiple major reverts so late in the beta period are unusual. He argued that increased bug-fixing demands diverted developer attention from release review, while fixes drafted with LLM help still require human review and may not meet PostgreSQL’s standards.
More Bug Reports Strain Release Work
The delay reflects a practical limit on how quickly a mature database project can process new findings: identifying a defect is only one step. A proposed correction must be checked for correctness and compatibility with the project’s standards, then reviewed and committed by developers. Haas said LLMs can help draft fixes, but that human review remains necessary.
For users and organizations planning upgrades, the immediate effect is uncertainty over when PostgreSQL 19 will be ready. The late reversions also mean some planned capabilities will not ship in this release. Haas characterized the delay as modest and connected it to the project’s focus on quality; the longer-term concern he raised is whether developers can keep pace with bugs that automated tools may increasingly uncover.
Products Worth Considering
Apple Watch SE (2nd Gen) GPS 40mm with Starlight Aluminum Case and Sport Band (S/M)
EcoFlow Delta 3 Ultra 3072Wh Portable Power Station – 3600W AC Output
Samsung Odyssey G4 25-inch FHD Gaming Monitor
As an affiliate, we earn on qualifying purchases.
A Departure From PostgreSQL’s Release Pattern
Haas wrote that PostgreSQL major releases have generally arrived between the middle of September and the middle of October over the past decade. PostgreSQL 19 is expected to fall outside that pattern, with November the likely earliest release timing and a further postponement still possible.
The project’s annual feature freeze takes place on April 8, according to Haas. Feature changes can be reverted after the freeze, but he described several large features being pulled between late August and mid-September as an unusual cluster. His account appeared on the Neon blog and was originally published on Haas’s blog. The explanation that LLM-assisted reports are a key cause is his assessment of the activity, rather than a formal project-wide finding.
No final PostgreSQL 19 release date is given in Haas’s account. November is his expectation, not a confirmed launch date, and he says a later postponement cannot be ruled out. The source does not provide a release schedule update from the PostgreSQL project itself.
The commit totals show a larger volume of work, but they do not identify the cause of every change or quantify the number of bugs found through LLMs. Haas acknowledges that other factors, including more mistakes by committers, could account for some of the increase, although he does not consider that the main explanation. The eventual status of the reverted features and the project’s plans for future releases are also not specified.
Maintainers Continue Fixes and Review
PostgreSQL developers must continue reviewing fixes and deciding whether the release is ready to ship. Haas’s account gives November as the likely timing but does not identify a specific next milestone, such as a revised release date or another beta schedule announcement.
Readers should watch for an official PostgreSQL project release update for confirmed dates and feature status. Haas said developers are working on how to handle the longer-term increase in findings, but described the response as unresolved; he offered no specific policy or tooling changes.
Key Questions
When is PostgreSQL 19 expected to be released?
Robert Haas said it most likely will not be released until November 2026. He also said a further delay is possible; no final date is included in his account.
Why does Haas say the release is delayed?
Haas links the delay to more bugs being reported with help from LLMs, which has increased the work needed to fix issues and review the release. He presents this as his explanation, not as a formal project-wide determination.
Which features were removed late in the beta period?
The reverted features were UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE … MERGE PARTITION/SPLIT PARTITION. Haas said the reverts happened between August 27 and September 15.
Do the commit figures prove LLMs found the additional bugs?
No. Haas’s figures show more commits to the stable branches during the compared periods, but they do not count distinct bugs or establish the cause of every commit. His claim that LLM-assisted reports drove much of the increase is an interpretation of the trend.
Source: rhaas.blogspot.com
