PostgreSQL 19 beta 4 shipped on September 24, 2026, and PostgreSQL's beta 4 announcement is blunt about what that status means: "This release contains PostgreSQL 19 feature previews ahead of general availability, though some details of the release can change during the beta period." Six items that existed in earlier PG19 betas got pulled between beta 3 and beta 4, and a team running PostgreSQL 16, 17, or 18 has real decisions to make this quarter, regardless of what ships at GA.
What PostgreSQL 19 beta 4 actually shipped (Sept 24, 2026)
The same announcement puts the next milestone at "the release candidate, which should occur in early October." From there, it adds a specific hedge: "Based on testing and evaluation, this means that the PostgreSQL 19 GA may also occur in October." That wording is an estimate. A team planning a Q4 upgrade window should treat October as the earliest realistic GA date, and build slack into the calendar in case the RC slips.
Nothing shipped in beta 4 is locked in yet. Details can still change before RC, and the revert list matters more than the feature list right now.
Six reverts since beta 3, stop planning around them
The beta 4 announcement lists six reverts made since the previous beta. Anyone who scoped work around these features needs to descope before RC lands and the feature set locks.
SQL/PGQ (property graph queries)
Property-graph query support, which would have let SQL statements traverse graph-shaped data directly, is reverted. Teams that planned to model graph relationships in PostgreSQL 19 need another approach for now.
Online checksum toggling
The ability to enable or disable data checksums on a running cluster without a restart is gone from this beta. Turning checksums on or off still means the older, more disruptive process.
Temporal updates via FOR PORTION OF
Support for temporal updates and deletes through a FOR PORTION OF clause is reverted. Any migration plan built around native temporal tables in PostgreSQL 19 needs to wait for a later release, if it returns at all.
MERGE PARTITIONS / SPLIT PARTITIONS
ALTER TABLE ... MERGE PARTITIONS and ALTER TABLE ... SPLIT PARTITIONS are both out. Partition maintenance in 19.0 stays on the same manual footing as earlier versions.
The removed pg_get_*_ddl() functions
pg_get_role_ddl(), pg_get_tablespace_ddl(), and pg_get_database_ddl() are removed outright, per the announcement, rather than merely reverted for now. Any tooling written against these functions during the earlier beta cycle needs to drop that dependency before RC.
The LC_COLLATE revert in the postmaster
The postmaster process no longer forces LC_COLLATE to C. That change from earlier PG19 betas is reverted, so collation behaviour in the postmaster stays the same as it was in PostgreSQL 18.
What survived: the features worth testing on a staging clone now
PostgreSQL 19's release notes describe what did make it through to beta 4 intact. None of it is final, but all five items below are stable enough to run against a staging clone today.
REPACK (replacing VACUUM FULL and CLUSTER)
A new REPACK command reclaims disk space and reorganizes table contents, combining what VACUUM FULL and CLUSTER used to do separately. Its CONCURRENTLY option repacks a table without blocking reads and writes against it, which is the part worth testing: an access-exclusive lock during a repack has been the standing complaint about the older commands for years.
WAIT FOR (read-your-writes on standbys)
The new WAIT FOR command waits until a standby has replayed changes up to a chosen point, which supports read-your-writes query patterns on standbys. Any staging scripts should use that exact syntax, since the announcement also notes several fixes for the command since beta 3.
Logical replication of sequences
Logical replication now carries sequence values along with table data, and it can be turned on without a server restart when wal_level is set to replica. Teams running logical replication for zero-downtime cutovers should test whether sequence drift, a known gap in earlier versions, actually closes here.
Parallel autovacuum index vacuuming
Autovacuum can now use parallel worker processes to vacuum a table's indexes, paired with a new scoring system that prioritizes which tables most need vacuuming or analyzing. On a cluster where autovacuum regularly falls behind on wide tables, this is worth benchmarking against the current single-worker behavior.
pg_plan_advice / pg_stash_advice
Two new extensions, pg_plan_advice and pg_stash_advice, aim to stabilize query planner decisions. pg_stash_advice applies stored advice automatically based on the query, which is the piece to test against known planner regressions rather than assuming it behaves like a query hint.
How to upgrade to PostgreSQL 19 once it's GA
1. Decide: pg_upgrade, dump/restore, or logical replication
The release notes' migration section keeps the same three options that have applied to every major PostgreSQL upgrade: "a dump/restore using pg_dumpall or use of pg_upgrade or logical replication is required for those wishing to migrate data from any previous release." That same migration section also flags two pg_upgrade blockers worth a pre-flight check: it disallows upgrading clusters whose database, role, or tablespace names contain carriage returns or line feeds, and it disallows upgrading clusters with btree_gist indexes on inet or cidr columns. Grep object names for stray CR/LF characters and find any btree_gist indexes on inet/cidr columns to rebuild before choosing pg_upgrade over the other two paths.
2. Test against a staging clone running beta 4 now
Waiting for GA to start testing wastes the beta window. Clone production data into a staging instance running beta 4, and run the REPACK, WAIT FOR, and logical replication scenarios above against real table shapes and query patterns, not synthetic benchmarks.
3. Recheck any code or tooling built around a reverted feature
If a migration plan, ORM extension, or internal script assumed SQL/PGQ, online checksum toggling, temporal FOR PORTION OF updates, partition merge/split, or the removed pg_get_*_ddl() functions, that code needs a fallback before RC. None of the five is guaranteed to return in a later beta.
4. Watch for the RC in early October
The vendor's early-October estimate for the release candidate is the next real checkpoint. Once RC ships, the feature set for 19.0 locks, and any remaining changes shift from feature scope to bug fixes.
The PostgreSQL 14 clock is separate, and shorter
PostgreSQL 19 beta 4 isn't the only deadline on the calendar. PostgreSQL's versioning policy sets the rule for every branch: "The PostgreSQL Global Development Group supports a major version for 5 years after its initial release. After this, a final minor version will be released and the software will then be unsupported (end-of-life)." Under that rule, PostgreSQL 14 reaches end-of-life on November 12, 2026, about seven weeks out from this beta's release date.
That date already came up once this year: the PostgreSQL 18.6 security release patched five branches at once in August and flagged the same November 12 cutoff in its own release notes. A team still running PostgreSQL 14 in production needs an upgrade owner and a target version on the calendar now, independent of anything happening in the 19 beta track. That target version matters for more than just PostgreSQL itself: any team also working through Django 6.1's compatibility table, which now requires PostgreSQL 15 or higher, should put both upgrades in the same maintenance window rather than running them twice.
FAQ
Is PostgreSQL 19 out yet?
No. Beta 4 shipped September 24, 2026, and the project's own announcement calls it a feature preview ahead of general availability. A release candidate is expected in early October, with GA possibly following in the same month, but neither date is confirmed.
What got removed from PostgreSQL 19 between beta 3 and beta 4?
Six items: SQL/PGQ property-graph query support, online checksum toggling, temporal updates and deletes via FOR PORTION OF, ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS, the pg_get_role_ddl(), pg_get_tablespace_ddl(), and pg_get_database_ddl() functions, and a revert that stops the postmaster from forcing LC_COLLATE to C. The five removed or reverted features would need to return in a later beta to make it into 19.0.
Can I upgrade straight from PostgreSQL 16 or 17 to 19?
The release notes describe the same three migration paths for any previous release: pg_dumpall dump/restore, pg_upgrade, or logical replication. The same migration section rules out pg_upgrade for clusters with carriage returns or line feeds in database, role, or tablespace names, and for clusters with btree_gist indexes on inet or cidr columns, so check for both before picking pg_upgrade over the other two paths.
When does PostgreSQL 14 lose support?
November 12, 2026. That's the end-of-life date set under PostgreSQL's five-year support window, and it applies regardless of when PostgreSQL 19 reaches GA.