PostgreSQL 19 Beta 4 Is Out: What Was Removed and Why PostgreSQL 14 Users Should Plan Now

On September 24, 2026, the PostgreSQL Global Development Group announced PostgreSQL 19 Beta 4. A fourth beta is usually a quiet housekeeping step, but this one is worth a closer look: the project removed several headline features from the release so that the rest of it can ship on a predictable schedule.

If your product runs on PostgreSQL, whether behind a Node.js development project, a Laravel application or a mobile app backend, two dates matter. PostgreSQL 19 is expected to reach general availability in October 2026, and PostgreSQL 14 receives its final update on November 12, 2026.

This article separates what is available today from what is only expected, and explains what a business owner or technical lead should do with that information.

What was announced on September 24, 2026

According to the project's announcement, the fourth beta of PostgreSQL 19 is available for download and contains previews of the features planned for the final version. The announcement adds a caveat that applies to every beta: some details can still change before the final release.

Status matters here. PostgreSQL 19 is a beta, not a production release. The announcement says the next planned step is a release candidate in early October, and that general availability "may also occur in October" depending on testing. That is an expectation from the project, not a fixed date.

The features removed from PostgreSQL 19

The most unusual part of the announcement is a list of features that were reverted, meaning they were in earlier betas and have now been taken out of version 19. The announcement lists the following:

• SQL/PGQ, the property graph query support that lets you query relational data as a graph
• Turning data checksums on and off while the database stays online
• Temporal updates and deletes using the FOR PORTION OF clause
• The ALTER TABLE commands for merging and splitting partitions
• Three functions that generate the definition statements for roles, tablespaces and databases

The project's stated reason is that PostgreSQL must be reliable above all else. Removing unfinished work late in a cycle is how the community protects that reputation and keeps its release timing predictable.

For most businesses this changes nothing in a running system, because none of these features exist in the version you use today. It matters only if a roadmap, a vendor proposal or an architecture document assumed that one of them would arrive with version 19. If your team was planning around graph queries or online partition splitting, that plan now needs a different approach or a later version.

What is still in PostgreSQL 19

The PostgreSQL 19 release notes list the major enhancements that remain. In plain terms, the highlights are:

• A new REPACK command that reclaims disk space and reorganizes a table, with a CONCURRENTLY option that avoids blocking reads and writes
• Logical replication that also copies sequence values and can be switched on without a server restart in a common configuration
• Autovacuum that can use parallel workers on a table's indexes and prioritizes the tables that most need attention
• A new command that waits until a standby server has caught up to a chosen point, which supports reading your own writes from a replica

The release notes also mention new extensions for stabilizing the query planner's decisions and performance work in several areas, including faster foreign key checks.

The practical theme is operational. Reclaiming space without downtime and smarter automatic maintenance address problems that growing applications run into after a few years of data, when tables bloat and maintenance windows become hard to schedule.

Changes that can break an upgrade

Every major PostgreSQL version includes incompatibilities, and the release notes list them in a migration section. A few are relevant beyond database specialists.

Authentication

The release notes state that RADIUS authentication support is removed, and that the server now issues a warning after a successful login that uses an MD5 password, a method the notes say was marked as deprecated in PostgreSQL 18. If any of your application accounts still use MD5 passwords, the warning is a prompt to move them to a stronger method.

Defaults and behavior

The notes say JIT compilation is now disabled by default, so sites that run many large analytical queries need to enable it manually. The default for max_locks_per_transaction changes from 64 to 128, and the notes explain that existing custom settings effectively need to be doubled to keep the same capacity. A json_array() call that returns no rows now gives an empty array instead of NULL, which can affect application code that checks for NULL.

Upgrade blockers

The notes describe cases where the pg_upgrade tool will refuse to proceed, including clusters that use certain btree_gist indexes on network address columns. The MULE_INTERNAL encoding is removed, and databases that use it must be dumped and restored with a different encoding. These are rare, but they are far cheaper to discover in a test than during a maintenance window.

PostgreSQL 14 reaches end of life on November 12, 2026

The more pressing date for many businesses is in the project's versioning policy. The policy says each major version is supported for five years after its initial release, after which a final minor version is published and the version becomes unsupported.

The table on that page shows PostgreSQL 14, first released on September 30, 2021, with a final release date of November 12, 2026. After that date the community publishes no further security or bug fixes for version 14. PostgreSQL 13 is already listed as unsupported.

The same table shows versions 15, 16, 17 and 18 as supported, with final release dates running from November 2027 to November 2030.

What this means for your business

The guidance below is our interpretation, not a statement from the PostgreSQL project.

First, treat the version 14 date as the real deadline. An unsupported database is a security and compliance exposure, because newly discovered vulnerabilities will not be patched by the community. If you use a managed database service, your provider sets its own timeline and may charge for or force upgrades, so check its documentation separately.

Second, do not plan a production move to version 19 on launch day. A newly released major version is usually adopted after it has seen some real-world use and after your hosting provider, framework and extensions confirm support. For a business leaving version 14 this year, an established supported version such as 17 or 18 is the lower-risk destination. That choice is a judgment call that depends on your stack.

Third, the removed features are a reminder not to build commitments on beta software. A feature is only real once it ships in a final release.

What to do next

Start by finding out which PostgreSQL version each of your environments runs. Production, staging and reporting databases often drift apart.

If anything is on version 14 or older, schedule the upgrade now. The release notes confirm that moving between major versions requires a dump and restore, pg_upgrade or logical replication, so it is a planned project with testing, not a routine patch. Budget time for testing the application against the new version, checking extensions and rehearsing the cutover.

If you are already on a supported version, ask your development team to run your test suite against the PostgreSQL 19 beta or release candidate in a non-production environment. The project explicitly asks users to test with their own workloads, and doing so tells you early whether the changed defaults affect you.

Conclusion

PostgreSQL 19 Beta 4, announced on September 24, 2026, trims several features to protect reliability and points to a release candidate in early October with general availability expected the same month. The more urgent item is PostgreSQL 14, which receives its final update on November 12, 2026.

Entrant Technologies builds websites, web applications, mobile apps and custom software. If you would like help assessing a database upgrade as part of a wider project, you can contact us to talk it through.