The PostgreSQL Global Development Group announces that the fourth beta release of PostgreSQL 19 is now available for download. This release contains PostgreSQL 19 feature previews ahead of general availability, though some details of the release can change during the beta period.
You can find information about all of the PostgreSQL 19 features and changes in the release notes:
https://www.postgresql.org/docs/19/release-19.html
The next planned release of PostgreSQL 19 is the release candidate, which should occur in early October. Based on testing and evaluation, this means that the PostgreSQL 19 GA may also occur in October. More details will be provided as we move closer to these releases.
This beta release reverted several features that were originally planned for PostgreSQL 19. The PostgreSQL community strongly believes that, first and foremost, PostgreSQL must be reliable. Additionally, the community strives for a predictable release schedule. Because of this, the community chose to remove some features from the PostgreSQL 19 release so they can be potentially be included in a later major release after more time working through the community development and review process.
Your testing and feedback help the community ensure that PostgreSQL 19 upholds our standards of delivering a stable, reliable release of the world's most advanced open source relational database. Please read more about our beta testing process and how you can contribute:
https://www.postgresql.org/developer/beta/
To upgrade to PostgreSQL 19 Beta 4 from an earlier version of PostgreSQL,
you will need to use a strategy similar to upgrading between major versions of
PostgreSQL (e.g. pg_upgrade
or pg_dump
/ pg_restore
). For more
information, please visit the documentation section on
upgrading.
Fixes and changes in PostgreSQL 19 Beta 4 include:
FOR PORTION OF
clause.ALTER TABLE ... MERGE PARTITIONS
and
ALTER TABLE ... SPLIT PARTITIONS
.pg_get_role_ddl()
, pg_get_tablespace_ddl()
, and
pg_get_database_ddl()
functions.LC_COLLATE
to C
in the postmaster process.REPACK
command, including crashes, incorrect
behavior with invalid indexes and materialized views, and several permission
and error-reporting corrections.WAIT FOR
command, including a deadlock and clearer
reporting of isolation-level errors.FOREIGN_JOIN
list in pg_plan_advice
.CREATE PUBLICATION ... EXCEPT
.COPY FROM
SIMD optimization.pgbench --continue-on-error
.Please see the release notes for a complete list of new and changed features:
https://www.postgresql.org/docs/19/release-19.html
The stability of each PostgreSQL release greatly depends on you, the community, to test the upcoming version with your workloads and testing tools to find bugs and regressions before the general availability of PostgreSQL 19. As this is a Beta, minor changes to database behaviors, feature details, and APIs are still possible. Your feedback and testing will help determine the final tweaks on the new features, so please test in the near future. The quality of user testing helps determine when we can make a final release.
A list of open issues is publicly available in the PostgreSQL wiki. You can report bugs using this form on the PostgreSQL website:
https://www.postgresql.org/account/submitbug/
This is the fourth beta release of version 19. The PostgreSQL Project is planning to move to the release candidate portion of the release cycle, and will continue to issue release candidates until PostgreSQL 19 is made generally available. For further information please see the Beta Testing page.
If you have corrections or suggestions for this release announcement, please send them to the pgsql-www@lists.postgresql.org public mailing list.
Facts Only
* The PostgreSQL Global Development Group released PostgreSQL 19 Beta 4.
* The release contains feature previews for PostgreSQL 19.
* A release candidate is planned for early October.
* General availability (GA) of PostgreSQL 19 may occur in October.
* Several originally planned features were removed from this release.
* Upgrading from earlier versions requires pgupgrade or pgdump/pgrestore.
* Beta 4 fixes include the FOR PORTION OF clause and ALTER TABLE MERGE/SPLIT PARTITIONS.
* New functions include pggetroleddl(), pggettablespaceddl(), and pggetdatabaseddl().
* SIMD optimization was added to COPY FROM.
* pgbench now includes a --continue-on-error flag.
* Bug reports are accepted via a web form on the PostgreSQL website.
* Open issues are listed on the PostgreSQL wiki.
Executive Summary
PostgreSQL 19 Beta 4 is now available, serving as a feature preview ahead of a projected October general availability. The development timeline suggests a release candidate will be issued in early October, though the final GA date remains dependent on the results of community testing and evaluation.
This specific beta iteration reflects a strategic decision by the community to prioritize system reliability and schedule predictability over feature density. Consequently, some planned features were reverted and deferred to future major releases to allow for more rigorous review. Technical updates in this version focus on partition management, DDL functions, and performance optimizations like SIMD for COPY FROM.
Users are encouraged to test the beta with their own workloads to identify regressions, as APIs and database behaviors may still undergo minor changes. Upgrading to this version requires standard major-version migration strategies.
Full Take
This communication is a standard technical announcement. The strongest version of this narrative is that of a mature, community-driven project practicing disciplined engineering by sacrificing "feature creep" in favor of stability and predictability.
The framing emphasizes a commitment to reliability as a core value. By explicitly stating that features were removed to maintain standards, the project signals a preference for conservative, high-assurance development over the rapid-release cycles common in proprietary software. This transparency serves to build trust with enterprise users who prioritize uptime over novelty.
The underlying paradigm is one of collective stewardship. The assumption is that the "community" is a monolithic entity with shared values, though in practice, this usually represents a consensus among the primary maintainers. The second-order consequence of this approach is a slower evolution of the software, which ensures stability but may leave the project vulnerable to competitors who iterate faster on high-demand features.
Patterns detected: none
If this were an influence campaign, a bad actor would use "stability" as a smokescreen to hide a lack of innovation or to mask the failure of specific internal development goals. However, the content here is a routine technical disclosure with no indicators of such a playbook.
Bridge Questions:
1. How does the decision to defer features impact the competitive landscape of open-source relational databases?
2. What metrics does the community use to define "reliable" versus "feature-complete" when deciding what to cut from a release?
3. To what extent does the reliance on community beta testing shift the burden of quality assurance from developers to end-users?