Postgres 19 is currently facing delays in its anticipated release schedule, a notable shift from the consistent fall launches of previous major versions. The development team is deeply engaged in a thorough review cycle, which has led to the reversion of several significant features during the beta phase. As it stands, Beta 4 is slated for September 24, 2026, but the release of Postgres 19 may be postponed by several weeks or even months.
This version was already ambitious, aiming to introduce numerous large features. However, the team has prioritized quality over a strict timeline, opting to narrow the scope of the release to ensure that it meets the high standards expected by its users. The ongoing code review process is functioning effectively, allowing for extensive testing and the removal of features that are not yet ready for deployment.
How PostgreSQL gets made
The PostgreSQL development process typically unfolds in the following manner:
- Community members contribute new patches during open commitfests, with discussions taking place on the Hackers mailing list.
- Approved patches are incorporated into future versions by one of the approximately 30 project committers.
- A beta version is released, followed by around six months of community testing, during which updates and bug fixes are applied, and some features may be reverted.
- Finally, a production version is launched, accompanied by quarterly maintenance releases for bug fixes and security updates.
Notable PG19 Feature Reverts
Since the beta phase commenced in June 2025, there have been 53 reverts for version 19, with several user-facing features being affected. Below are some of the more significant reversions:
SQL Property Graph Queries (SQL/PGQ)
This feature aimed to introduce graph query views atop tables, but concerns regarding broader design and readiness led to its reversion.
ALTER TABLE MERGE/SPLIT PARTITION(S)
A long-requested feature for partition management, this was reverted due to design issues that could not be resolved in the current release cycle.
UPDATE/DELETE FOR PORTION OF
This feature was intended to enhance temporal range column handling but was reverted following testing that revealed issues.
GROUP BY ALL
A post-commit review uncovered that this feature failed to account for special handling of ORDER BY entries with nondefault equality semantics, resulting in incorrect outputs.
Default TOAST compression change to lz4
This change was found to lack necessary support in the buildfarm, prompting the team to postpone it until compilation issues are resolved.
Nontext output formats for pg_dumpall
Active bugs identified during the post-commit review led to this feature being deferred for future versions.
JSON_TABLE ON ERROR cascading
This feature, which aimed to apply table-level ON ERROR cascades to columns, was reverted due to reported bugs.
Fast default for domains with nonvolatile constraints
Implementing a proper fix requires enhancements to the Table Access Method API, making it unsuitable for inclusion in v19.
Logical replication database-specific snapshots
This feature relates to logical replication supporting the REPACK functionality, which remains limited to a single process running concurrently across various tables and databases.
Nested query tracking (pg_stat_statements)
This feature aimed to provide clearer mappings between query IDs and query strings, but syntax issues arose during testing.
Online data checksums
This feature would allow users to check for data corruption while pg is still operational, but it has faced challenges in its implementation.
Common pattern with the reversions
The majority of significant feature reversions stemmed from design flaws identified during post-commit reviews, incorrect results, or compatibility issues discovered too late in the release cycle. Many of these features are expected to be revisited in version 20.
At-risk Postgres 19 features
A variety of bugs and issues have been reported for features in the pg19 beta, indicating that further reversions may be on the horizon. Robert Haas, a key contributor to the project, recently conducted a scary bug contest utilizing AI assistance to identify potential risks, including:
- RI fast-path FK checks
- REPACK / REPACK CONCURRENTLY
- Postgres_fdw statistics import
Additionally, PostgreSQL maintains an open items wiki to track bugs and outstanding issues awaiting resolution. As version 19 progresses, further discussions and evaluations are anticipated.
Still shipping
Despite the challenges, there are still several promising features in PG19 to anticipate:
- pg_plan_advice and query plan hints
- Parallel autovacuum
- ON CONFLICT DO SELECT, enabling upserts to return existing rows
- IGNORE NULLS in window functions
- Numerous logical replication enhancements
It is essential to recognize that each PostgreSQL version encompasses a multitude of additional features, bug fixes, performance improvements, and advancements in query planning. Thus, even when some headline features are withdrawn, the latest production version of Postgres consistently represents a progressive step forward.
The AI factor
Artificial intelligence plays a significant role in the current development landscape, with many contributors utilizing AI tools to identify bugs and create reproducible test cases. Given the complexity of some fixes, it is often more pragmatic to defer these features to future releases.
For instance, consider the evolution of CVE patching in PostgreSQL: previously averaging a couple of CVEs per release, the August 2026 patch for Postgres 18 addressed 28 CVEs. While PostgreSQL does not yet have an official AI contribution policy, one is anticipated in the near future.
What is different about PG 19?
Similar to prior versions, Postgres 18 also experienced a significant number of reversion cycles, totaling around 44. However, as of now, Postgres 19 has seen 53 reversions, many of which pertain to major features such as graph queries and GROUP BY ALL, drawing considerable attention. The key distinction lies in the timing of these reversions, which are largely the result of detailed AI-generated reviews.
What this means
The delay of a major release is a rarity for Postgres, especially in an era characterized by rapid deployment and the pressures of AI integration. The dedication of the core team to maintaining rigorous standards is commendable.
- There is no cause for concern—the release process is functioning effectively. Features that are not ready are being appropriately removed, and the rationale behind these decisions is transparent. AI is aiding in the identification of potential issues.
- Postgres 18 remains a reliable upgrade target for users at this time.
- Features such as property graphs, GROUP BY ALL, and partition merge/split are now earmarked for inclusion in PG20.
- Additional features may also be reconsidered, so it is advisable to monitor discussions on the hackers list.
