PostgreSQL 19 is late. It was expected in late September or early October; the new target is around 19 November. Between eight and ten notable features have also been pulled and pushed to PostgreSQL 20.

Peter Eisentraut, one of the project's leading committers and a vice president at EDB, named one of the reasons. Over recent months, code review with language models has become noticeably sharper and surfaced a long tail of small edge-case defects. In the past, bugs like these would have trickled in over the years after release.

Why not just fix them

Each report on its own is a couple of lines. But every one carries a fixed cost: understand it, discuss it, verify it. When a single feature collects forty reports, you run out of time before the deadline. Some of the postponed features, Eisentraut says, also had architectural problems that could not be solved quickly during beta.

He was clear that vibe coding had nothing to do with it. The main features were written before tools like these existed. The quality bar simply went up after the code was already committed.

What went and what stayed

  • Gone: SQL/PGQ, the property graph queries from the SQL:2023 standard
  • Staying: REPACK CONCURRENTLY, which reclaims disk space without the table lock that VACUUM FULL takes
  • The postponed features will likely land in PostgreSQL 20, which until recently was planned as a bug-fix-only release

Our take

For a site owner this is mostly good news: version 19 arrives later but cleaner. There is still no reason to rush onto a fresh major version — wait for the first minor update and rehearse the migration on a copy of the database. The episode also shows where AI is changing development most right now: less in writing code than in checking it. Details are in The Register's report.