PostgreSQL 19 has not shipped, and it is getting smaller. Two features were reverted out of the release in the last two weeks.
On September 7, SQL/PGQ property graphs were reverted. That removed 47 commits: the feature and every fix built on it since. On August 27, ALTER TABLE … MERGE/SPLIT PARTITION was reverted, removing 14 more. The reason is in the commit message: “multiple design issues which are too late to address in this release cycle.”
Both reverts landed after Robert Haas asked the pgsql-hackers list on August 25 whether any of six heavily patched features should come out before 19 ships. One of the two was on his list. One was not.
What this changes for you
If any part of your 2027 plan assumes a PostgreSQL 19 feature, check that the feature is still in PostgreSQL 19.
Three of the six features Haas named are still taking fixes. UPDATE/DELETE FOR PORTION OF took three in this window, two of them on September 8. REPACK is still having its scope narrowed rather than its bugs fixed: as of September 8 you cannot run REPACK (ANALYZE) inside a transaction block, which the commit calls a temporary stopgap for a future release.
Online data checksums and postgres_fdw statistics import have gone quiet. So has the fast-path foreign key work, which has produced nothing since August 22.
What we recommend
Run your upgrade planning against PostgreSQL 18, or stay where you are on a supported version and move when 19 has released a few minor versions. That doesn't mean you shouldn't also be testing 19 to help it get where it needs to be for your production work loads.
If you are on PostgreSQL 14, that version reaches end of life on November 12th, 2026, and that deadline does not move because 19 is unsettled. Audax Postgres keeps 14 supported past that date while you wait for a release you trust.
If you want to know what is actually landing in 19 rather than what was announced for it, we track the stabilization branch commit by commit and publish what changed. If you would rather someone else watch it, that is what our Proactive SLA is for.
In conclusion
PostgreSQL’s release process is doing its job. Features that are not ready are coming out, in public, with the reasoning written down. That is the system working, and it is a good argument for trusting Postgres.