The PostgreSQL Global Development Group said on 15 October 2026 that the first release candidate of PostgreSQL 19 is out and that general availability is planned for 19 November 2026, after a second release candidate on 12 November.
The Register reported on 16 October that the release was once slated for late September or early October. Peter Eisentraut, a leading PostgreSQL committer, wrote on 9 October that “about 8 to 10 significant features” had been reverted from the PostgreSQL 19 branch, and said LLM-assisted code review was part of why.
Business Pill · THE AI AUDIT PROBLEM
A one-minute explainer of the AI audit problem: what happens when making work becomes cheaper than checking it. It teaches the general idea only and says nothing about PostgreSQL or anyone in this story.
The key insight: As we read it, the delay is a review-capacity story: Peter Eisentraut wrote that LLM-assisted code review surfaced defects in older features much faster, leaving developers “staring at a list of like forty defect reports”, and the project now plans general availability of PostgreSQL 19 for 19 November 2026.
“The planned date for the general availability of PostgreSQL 19 is November 19, 2026,” the PostgreSQL Global Development Group said in its 15 October announcement of PostgreSQL 19 RC 1.
The announcement says the next scheduled update release for supported versions, on November 12, 2026, “will include a large number of fixes”, and that the release team decided to include these fixes in PostgreSQL 19 before its general availability. A second release candidate, PostgreSQL 19 RC 2, will be available on the same day as the update release, it says.
Fixes applied during the Beta 4 period include several for REPACK (CONCURRENTLY), for pg_plan_advice and for parallel autovacuum, the announcement lists.
The PostgreSQL Global Development Group plans general availability of PostgreSQL 19 for 19 November 2026, after RC 2 on 12 November (announcement of 15 October 2026); The Register says the release was once slated for late September or early October.
Why Features Were Reverted
“Having some reverts is not unusual, maybe one per cycle could be expected,” Eisentraut wrote. “But this time around, about 8 to 10 significant features, depending on how you count, have been reverted, and some of them quite late in the beta period.”
He offered several possible reasons and said it was “probably a combination of these”. Some reverted features “had significant architectural defects that would have been hard to fix quickly and during beta.”
There was also a long tail of smaller issues, he wrote: “But with LLM-assisted code review, these kinds of things can get found much faster, and then you’re staring at a list of like forty defect reports.” He added that “even if each of them requires only a three-line fix on average, there is a fixed overhead to dealing with each of these, and then you run out of time.”
Not Vibe Coding, Eisentraut Says
Eisentraut wrote that most if not all of the affected features were written when LLM-assisted code review was not as useful as it is now, “meaning that the effective quality bar has been raised after the time the feature was written and committed.”
“At least for the most part, as far as I can tell, this situation is not due to” vibe coding, he wrote. “This code was written well before that was a possibility.”
He also pointed to security work: many senior developers were busy between April and August with fixes for security issues, he wrote, so the usual review and testing during beta was reduced. And he suggested that “LLM-assisted fuzzing can find problems with this really quickly” for complex feature interactions.
What Was Pulled and What Stays
Among the features pulled is support for SQL Property Graph Queries (SQL/PGQ), which became part of the SQL standard in 2023, The Register reported. It quoted PostgreSQL contributor Tom Lane: “At this point I’d be willing to bet dinner that if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20.”
“PostgreSQL 19 will still be a great release,” Eisentraut wrote, naming REPACK CONCURRENTLY, logical replication of sequences and planner hinting with pg_plan_advice. The Register says the reverted features will likely make it into PostgreSQL 20. This week we wrote about Anthropic’s junior tech hires and agent hours, and about Claude tracing the NIST curve seeds.
The Structural Read
As we read it, the bottleneck Eisentraut describes is fixing, not finding: he wrote that even a three-line fix carries “a fixed overhead to dealing with each of these, and then you run out of time.”
As we read it, the timing compounded it: Eisentraut wrote that many senior developers spent April to August on security fixes, so the usual beta review was reduced and picked up again in August.
As we read it, his remedy points the tools at development itself: he wrote that LLM-assisted fuzzing “can find problems with this really quickly” and that this probably needs to be part of feature development in the future.
Peter Eisentraut, blog post (9 October 2026)
“the effective quality bar has been raised after the time the feature was written and committed”
Three Implications
POSTGRESQL USERS The announcement plans general availability for 19 November 2026, with RC 2 on 12 November; Eisentraut says PostgreSQL 19 will still be a great release, naming REPACK CONCURRENTLY, logical replication of sequences and pg_plan_advice.
OPEN-SOURCE MAINTAINERS Eisentraut wrote that the community preferred trying to stick to the release schedule rather than delaying to get more fixes in, and that it has been contemplating committing features with some kind of “experimental” status.
TEAMS ADOPTING AI CODE REVIEW Eisentraut wrote that most if not all of the reverted features were written when LLM-assisted code review was not as useful as it is now, and that the situation should sort itself out unless those capabilities keep improving at the current rate.
The framework argues: “Universal harnesses are likely to dominate highly digital, modular, and verifiable work”.
As we read it, database code is that kind of work: Eisentraut wrote that no one can manually test or even enumerate the edge cases, while LLM-assisted fuzzing can find problems quickly. The framework predates the announcement and does not discuss PostgreSQL.
Per Peter Eisentraut’s blog post (9 October 2026): with LLM-assisted code review, “you’re staring at a list of like forty defect reports”, each requiring “only a three-line fix on average”; about 8 to 10 significant features were reverted from the PostgreSQL 19 branch.
What Is Not Established
Eisentraut presents his explanation as his own opinions. The announcement does not explain why general availability moved from the late September or early October timing The Register reported; neither source lists all of the reverted features or counts how many defects came from LLM-assisted review.
We read the PostgreSQL Global Development Group’s announcement, Eisentraut’s blog post and The Register’s article in full on 17 October 2026. We did not contact the PostgreSQL project or Eisentraut.
Business Engineer Framework
The Agentic Harness War
A Business Engineer framework on how agent harnesses consolidate or proliferate across kinds of work.
The PostgreSQL Global Development Group plans general availability of PostgreSQL 19 for 19 November 2026, after a second release candidate on 12 November, and committer Peter Eisentraut wrote that about 8 to 10 significant features were reverted from the branch.
Eisentraut attributed part of that to LLM-assisted code review surfacing “a list of like forty defect reports”, and said the situation is not due to vibe coding.
A note on sourcing. We read in full the PostgreSQL Global Development Group’s announcement “PostgreSQL 19 RC 1 Released!” (15 October 2026), Peter Eisentraut’s blog post (9 October 2026) and The Register’s article (16 October 2026) on 17 October 2026; every quotation and figure comes from those texts. We did not contact the PostgreSQL project or Eisentraut. The references to our earlier reporting link to our own pieces.
Gennaro Cuofano is a CRO and tech executive who has worked in AI since late 2015, starting with bringing NLP, natural-language generation, voice and chatbot products to the marketing industry. His background is in law and finance: he holds a Master's degree in Law and an International MBA with an emphasis on corporate finance (LUISS Business School and the University of San Diego, 2012), and worked as a financial analyst at a real-estate investment firm in San Diego and as an assistant controller. His work focuses on business model strategy, business engineering and, more broadly, structural analysis: how companies make money, read from their own filings. He created FourWeekMBA and leads research there and at The Business Engineer, his newsletter on AI and business strategy, with over 95,000 subscribers and more than 1,000 published analyses. His writing has also appeared on Entrepreneur, HackerNoon and Search Engine People. Find him on LinkedIn and Substack. See how we source.
Scroll to Top
Discover more from FourWeekMBA
Subscribe now to keep reading and get access to the full archive.
