PostgreSQL 19 Beta 4 removes features before the release candidate

PostgreSQL 19 Beta 4, released on September 24, removes several capabilities that appeared in earlier previews. The announcement names SQL/PGQ property graph queries, temporal updates and deletes, and partition split and merge commands among the reversions. It also removes online changes to data checksums and several DDL-producing functions. These are substantive changes to what an application or operating procedure can expect from PostgreSQL 19.

The project explains the decision in terms of reliability and a predictable release schedule. It plans to move into release candidates next, with the next candidate expected in early October. General availability may also occur in October, depending on testing and evaluation. As of this announcement, those are plans. I would use Beta 4 to reassess dependencies on preview behavior before treating a major-version upgrade plan as ready.

I have used PostgreSQL for twenty-nine years and still choose it by default for relational systems. Its predictable behavior matters more to that preference than the number of additions in a release. I support removing a preview capability when the project judges that it needs more review. For an application that expected to use it, however, the removal creates concrete design work that deserves more detail than an approving comment about release discipline.

Earlier previews are no longer the right capability list

The Beta 1 announcement presented SQL/PGQ as a way to execute property graph queries with SQL-standard syntax. Beta 4 explicitly reverts that support. A design based on that preview therefore needs to revisit its assumed database interface. A working experiment on an earlier beta does not establish that the same SQL belongs in a PostgreSQL 19 deployment plan.

I would first identify where the application depends on the removed syntax. That includes schema work and queries retained in tests, as well as the main application code. The next question is which behavior the application actually needs. I would choose an alternative only after making that requirement explicit, because the removal announcement does not prescribe a replacement graph implementation or establish equivalence with another query model.

The temporal change has a similarly precise scope. Beta 1 described FOR PORTION OF support for UPDATE and DELETE, complementing temporal constraints added in PostgreSQL 18. Beta 4 reverts those update and delete capabilities. It does not announce the removal of PostgreSQL 18's temporal constraints. I would keep those distinctions intact when reviewing a schema that combines existing constraints with planned new modification syntax.

An application can therefore need changes to its planned write operations without having the same change to every temporal constraint it uses. I would test the actual statements against Beta 4 and identify the unsupported operations directly. A broad description such as temporal support being removed would obscure the boundary established by the announcement and could lead to unnecessary redesign of unaffected parts.

Operational plans can depend on preview features too

ALTER TABLE ... MERGE PARTITIONS and ALTER TABLE ... SPLIT PARTITIONS are also reverted. Their earlier announcement described reorganizing partitioned tables in place. An operations plan that assumed those new commands needs reassessment, even if the application's ordinary queries do not contain them. This is why I would include maintenance scripts in the search for preview dependencies.

I would retain the intended partition layout and the reason for the reorganization as the requirement. Then I would evaluate a procedure supported by the version actually being deployed. The Beta 4 announcement does not establish that an alternative will have the same locking or resource behavior as the removed commands. Assuming equivalence would turn a missing feature into an untested operational change.

Online enabling and disabling of data checksums is another removed capability. Beta 1 had described changing checksums without a cluster restart or reinitialization. Its removal affects the procedure an operator can plan for that transition. It would be inaccurate to describe this as removing data checksums themselves, because the announced reversion concerns changing their state online.

For me, the practical response is to remove the preview operation from any planned maintenance automation and review the supported procedure separately. I would preserve the requirement to verify the resulting checksum state. Testing a script that depended on the earlier preview is useful, but a successful run against the older beta would no longer validate the intended deployment target.

The removed DDL functions are named explicitly as pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl(). Beta 1 described them as helpers for scripting and migration. If a tool adopted those functions during beta testing, that dependency needs attention alongside application SQL. An upgrade assessment limited to business queries would miss it.

The retained features still have correctness work

Beta 4 also contains fixes for capabilities that remain in the preview. The announcement lists several corrections to REPACK, including crashes and problems involving invalid indexes or materialized views. It also mentions permission and error-reporting corrections. Those details give an operator specific failure cases to consider when evaluating the command on this beta.

I would keep tests of invalid or incomplete state where they are relevant to the intended workflow. A successful operation on an uncomplicated table would not exercise the cases named in the announcement. That does not mean every application needs a comprehensive test of every new command. It means that adopting one of these operations creates a reason to include the conditions its own procedure can encounter.

The new WAIT FOR command receives fixes including a deadlock correction and clearer reporting of isolation-level errors. Beta 1 described waiting for a log position to be replayed on a replica before executing a query. For an application evaluating that pattern, I would include the wait in its test and check the expected error handling. Testing only the subsequent query would leave the coordination step unexamined.

Logical replication has several corrections too. Beta 4 fixes initial table synchronization from an older PostgreSQL version to version 19, as well as conflict detection. It also fixes cases involving CREATE PUBLICATION ... EXCEPT. These are relevant to an upgrade rehearsal that uses replication, especially when the rehearsal is supposed to represent a source server on an older major version.

I would preserve the source version and publication definition in any report of a replication failure. They are part of the conditions the announcement identifies. A reproduction that replaces the source with another PostgreSQL 19 beta may simplify the environment, but it may also remove the cross-version case the test was intended to assess.

The autovacuum scoring system also receives corrections, including cases involving TOAST tables. I would include representative stored data when evaluating maintenance behavior, rather than limiting the environment to empty schema definitions. This is a testing priority suggested by the announced fixes, not a claim that every TOAST table has experienced a failure. The distinction matters when reporting results, since a useful report identifies the observed behavior and the conditions that produced it without generalizing beyond the evidence.

Release planning remains conditional on testing

The project's roadmap explains that PostgreSQL has no formal feature requirements that each release must contain. Developers can explore topics of their choosing, while contributors and committers review new work. That context helps explain why removing a feature can be compatible with continuing toward a release. The project is not describing an obligation to retain every earlier preview at any cost.

The Beta 4 announcement says removed features may be included in a later major release after further development and review. It does not assign them to a particular version. I would avoid planning around an assumed return date. If an application needs one of those capabilities before adopting PostgreSQL 19, the current announcement supplies no replacement delivery commitment on which to base that dependency.

Upgrading to Beta 4 from an earlier version requires a strategy similar to a major upgrade, such as pg_upgrade or dump and restore. The project continues to request testing and warns that behavior and interfaces can still change during the beta. I would allocate time for rebuilding or upgrading the test environment instead of treating each beta as an interchangeable binary replacement.

My immediate review would compare the planned application's required SQL and its operating procedures against Beta 4. I would then rerun the relevant integration tests with the intended source versions and connection paths. For any removed capability, the resulting plan should identify the replacement procedure or the dependency that remains unresolved, so the release candidate can be assessed against an accurate set of requirements.