The PostgreSQL Global Development Group released PostgreSQL 19 Beta 4 on September 24. This beta reverted several features originally planned for 19.

The reverted features are SQL/PGQ (property graph queries), online enabling and disabling of data checksums, temporal updates and deletes via the FOR PORTION OF clause, and ALTER TABLE ... MERGE/SPLIT PARTITIONS. Three DDL output functions, including pg_get_role_ddl(), were also removed.

The group said PostgreSQL must first and foremost be reliable, and that it strives for a predictable release schedule. The removed features may land in a later major release after more review.

Moving from an earlier version to Beta 4 requires the same approach as upgrading between major versions, such as pg_upgrade or pg_dump/pg_restore.

According to the upgrade docs, minor releases never change the internal storage format, so replacing the executables is enough. Major releases can change it, so data moves via dump and restore, pg_upgrade or logical replication.

The docs say running the new server in a different directory and port alongside the old one gives the least downtime, and give this transfer command as an example.

pg_dumpall -p 5432 | psql -d postgres -p 5433

The docs note that new major versions typically bring user-visible incompatibilities. So they point to the Migration section of the release notes and list administration, SQL, library API, system catalogs and server C API changes as testing categories.

Caveats: still a pre-release beta

The announcement says the next planned release is a release candidate in early October, and GA may also occur in October based on testing and evaluation. It is not a confirmed release date.

The announcement says minor changes to database behavior, feature details and APIs are still possible during the beta. Features not on this revert list are not final either.

The 19 docs may also change before release. This article does not include results from actually migrating a database or extensions.

A migration test plan without the reverted features

If work began using reverted syntax after an earlier beta, marking those parts is the first step.

Next, the chosen migration method is rehearsed on representative data, and extensions and admin tools are checked on the new version. Keeping a path that works without new features lets the migration itself be judged even as the feature set changes.

In PostgreSQL 19 Beta 4, the revert list and the major-upgrade procedure are changes on separate axes.