What Is Happening with PostgreSQL 19?

Postgres 19 won't make the expected release date. PostgreSQL has shipped its major version every fall for the last several years. But this year, the code is in a heavy review cycle, major features have been reverted during beta, and many others are under heavy revision. Beta 4 is scheduled for Sept. 24, 2026. A release of Postgres 19 is certainly delayed by weeks and maybe even months.

Postgres 19 was an ambitious release already, with a lot of large features. With any project, you have to choose priorities. For Postgres, the priorities were quality, followed by shipping within the time window. The team is reducing the scope of the release to get closer to meeting its timeline with the quality it requires.

I'll break down some of the major reversions in Postgres 19. While this is a long list, I want to make it abundantly clear that the PostgreSQL code development process is working beautifully. Code is getting tested at a wide scale and things that aren't ready are getting pulled.

How PostgreSQL gets made

A typical PostgreSQL code development process works like this:

• New patches are added by the community in a series of open commitfests and discussed on the Hackers mailing list
• Patches selected for approval are added to a future version by one of the ~30 project committers
• A beta version is cut, the community starts testing for ~6 months, updates and bugs are patched and some features are reverted
• A final production version is released, followed by quarterly maintenance versions for bug patches and security updates

Notable PG19 Feature Reverts

There have been quite a few reverts for version 19 of Postgres: 53 since the beta began in June 2025. Below are some of the more major user-facing features you may be familiar with:

SQL Property Graph Queries (SQL/PGQ)

Property graphs would add graph query views on top of tables and a light approach to graph queries in Postgres. The hackers discussion suggests broader design and readiness concerns.

ALTER TABLE MERGE/SPLIT PARTITION(S)

This has been a long-requested feature for partition management. The reversion discussion cites design issues which are too late to address in this release cycle.

UPDATE/DELETE FOR PORTION OF

This was an exciting update for temporal range columns for Postgres to handle some boundary time math.

GROUP BY ALL

A post-commit review found it missed special handling of ORDER BY entries with nondefault equality semantics, producing wrong results.

Default TOAST compression change to lz4

This feature would change TOAST compression. The team discussed this was missing some support in the buildfarm, so this will be reworked later with project compilation issues are sorted out.

Nontext output formats for pg_dumpall

Active bugs were found on post-commit review, but work on this will continue in future versions.

JSON_TABLE ON ERROR cascading

This feature made table-level ON ERROR cascade to columns (per SQL standard), and was reverted due to bugs reported.

Fast default for domains with nonvolatile constraints

A proper fix requires additions to the Table Access Method API and thus it is not ready for v19.

Logical replication database-specific snapshots

This is related to the logical replication supporting the REPACK feature. That is now limited to a single process that can run concurrently across different tables and databases. Luckily it looks like REPACK is still in V 19.

Nested query tracking (pg_stat_statements)

This gives cleaner mappings between query ID and query strings, but some syntax issues were found during testing.

Online data checksums

You can use checksums to check for data corruption. This would let you change your checksum settings while pg is still running.

Common pattern with the reversions

Most big features were reverted because of design flaws found in post-commit review, wrong results or compatibility concerns discovered too late in the release cycle. Most of these will be tried again in v20.

At-risk Postgres 19 features

There is a long list of bugs and issues reported for features in this pg19 beta that have yet to be completely addressed, so more feature reversions are possible. Robert Haas, one of the project's major contributors, ran a scary bug contest with AI assistance code showing what else might be at risk. These include:

• RI fast-path FK checks
• REPACK / REPACK CONCURRENTLY
• Postgres_fdw statistics import

PostgreSQL also keeps an open items wiki bugs, things waiting for fixes per version. I expect a lot more discussion as version 19 makes its way to the finish line here.

Still shipping

I think we still have some good features in PG19 to look forward to:

• pg_plan_advice and the query plan hints features
• Parallel autovacuum
• ON CONFLICT DO SELECT, so upserts return existing rows
• IGNORE NULLS in window functions
• Many of the logical replication improvements

It's also worth noting here that each PostgreSQL version has a lot of other features, bug fixes, performance improvements and query plan advancements. So even when the headline features are pulled, the newest production version of Postgres is virtually always a step forward.

The AI factor

AI has to be part of the story for why we're in this situation. Several folks are using AI tools to find bugs and create valid reproducible test cases. The fixes are fairly large, so pushing to a future version makes the most sense for many of these features.

If you want an example of how AI is changing PostgreSQL's deployment pipeline, think about CVE patching. PostgreSQL used to average a couple CVEs each release; the August 2026 patch for Postgres 18 had 28 CVEs.

PostgreSQL currently has no official AI contribution policy, though one is expected soon.

What is different about PG 19?

Postgres 18 and prior versions had major reversion cycles too. Postgres 18 had about 44 and we're currently at 53 for pg 19. Postgres 18's were a bit earlier, most of them coming shortly after beta. Many of these Postgres 19 issues are with major headline features like graph queries and GROUP BY ALL so they are catching our attention. The only real difference here is that they are late-breaking reversions, many of them from in-depth AI-generated reviews.

What this means

Delaying a major release is something that has not happened with Postgres in a long time. In an age of ship-ship-ship and AI rush, the human rigor of the Postgres core team is admirable.

• Don't worry - the release process is working! This is a good thing! Features that aren't ready get pulled. The reasoning is public. AI is helping us catch more things.
• PG18 is the safe upgrade target today.
• Property graphs, GROUP BY ALL and partition merge/split are now PG20 material.
• Other features may get pulled too, watch the hackers list.