PostgreSQL 19 is slipping from its traditional late-September/early-October window to November 19, with eight to 10 significant features yanked and deferred to PostgreSQL 20. The reason is not that the code got worse — it's that the reviewers got better, mid-cycle, in a way nobody planned for. Peter Eisentraut, a leading PostgreSQL committer and VP at EDB, attributes the disruption to LLM-assisted code review that matured dramatically between the time features were written and the pre-release review window. The AI reviewers surfaced roughly 40 defect reports across edge cases that human reviewers would likely have caught piecemeal over the next five years of post-release maintenance. Each fix was small — averaging three lines — but the fixed overhead per report drained the available calendar. Several reverted features had deeper architectural problems. Among the most notable casualties is SQL Property Graph Queries (SQL/PGQ), a syntax for traversing node-edge relationships that became part of the SQL standard in 2023. Contributor Tom Lane warned before the revert that shipping it in v19 would guarantee post-release bugs "unfixable until v20." The team agreed. Eisentraut was explicit that this is not a vibe-coding story. The features were written before LLM-assisted development was practical; the AI showed up only on the review side, and only became effective in the months before launch. The asymmetry is the point: code written to one quality bar was evaluated against a higher one that emerged after commitment. The structural question is whether this is a one-time adjustment or a recurring pattern. Eisentraut expects it to stabilize: "Unless the capabilities of LLM-assisted code review keep improving at the current rate, this situation should sort itself out for future development cycles." That conditional is doing heavy lifting. If LLM review capability keeps climbing, every release cycle faces a moving quality target. PostgreSQL 20, previously expected to be a maintenance-only release with no new features, will now absorb the reverted features from 19. The delay compresses the gap between the two releases in terms of feature content while stretching v19's calendar. The project keeps REPACK CONCURRENTLY — which avoids the table-locking VACUUM FULL operation — as a headline improvement. The broader signal here extends well beyond PostgreSQL. Any large open-source project with a multi-month development-to-review pipeline is now exposed to the same asymmetry: tools that improve faster than the code they inspect. The cost is schedule disruption. The benefit is shipping fewer five-year-old bugs on day one.
