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. A typical PostgreSQL code development process works like this: 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: 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. 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. This was an exciting update for temporal range columns for Postgres to handle some boundary time math. A post-commit review found it missed special handling of ORDER BY entries with nondefault equality semantics, producing wrong results. This feature would change TOAST compression. The team discussed this was missing some support in the buildfarm, so this will be reworked later when project compilation issues are sorted out. Active bugs were found on post-commit review, but work on this will continue in future versions. This feature made table-level ON ERROR cascade to columns (per SQL standard), and was reverted due to bugs reported. A proper fix requires additions to the Table Access Method API and thus it is not ready for v19. 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. This gives cleaner mappings between query ID and query strings, but some syntax issues were found during testing. You can use checksums to check for data corruption. This would let you change your checksum settings while pg is still running. 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. 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: 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. I think we still have some good features in PG19 to look forward to: 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. 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. 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. 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.How PostgreSQL gets made
Notable PG19 Feature Reverts
SQL Property Graph Queries (SQL/PGQ)
ALTER TABLE MERGE/SPLIT PARTITION(S)
UPDATE/DELETE FOR PORTION OF
GROUP BY ALL
Default TOAST compression change to lz4
Nontext output formats for pg_dumpall
JSON_TABLE ON ERROR cascading
Fast default for domains with nonvolatile constraints
Logical replication database-specific snapshots
Nested query tracking (pg_stat_statements)
Online data checksums
Common pattern with the reversions
At-risk Postgres 19 features
Still shipping
The AI factor
What is different about PG 19?
What this means