PostgreSQL 19: Graph Queries Reverted Before Release

In the final weeks before PostgreSQL 19's expected general-availability release, the project's maintainers pulled two features that had already been merged and beta-tested: SQL/PGQ property graph queries, reverted on September 7, 2026, and ALTER TABLE ... MERGE/SPLIT PARTITION, reverted on August 27, 2026. Both were cut not because they were unfinished ideas, but because senior contributors judged the code not solid enough to support for the next five years of PostgreSQL's release lifecycle. PostgreSQL 19 itself is still on track for general availability around September or October 2026, currently at beta 3, but it will ship without the graph-query syntax it was expected to headline.

What happened, in order

PostgreSQL follows an annual major-release cadence, and 19 has been moving through the normal cycle: beta 1 on June 4, 2026, beta 2 in July, and beta 3 on August 13, 2026 (which also fixed 28 security-related issues and over 110 bugs across the whole supported line, per the project's own release announcement). Beta 3 was expected to be close to feature-complete, with only bug fixes and polish left before release candidates.

That changed on August 25, 2026, when core contributor Robert Haas asked the pgsql-hackers mailing list a blunt question: of the features that had gone through unusually heavy post-merge patching, were any of them actually not ready? Six were named as candidates for discussion.

Two failed the test:

`ALTER TABLE ... MERGE/SPLIT PARTITION` was reverted on August 27, removing 14 commits. The stated reason was "multiple design issues which are too late to address in this release cycle."
SQL/PGQ (SQL Property Graph Queries) — the ability to run GRAPH_TABLE queries and define CREATE PROPERTY GRAPH views over existing relational tables, standardized in SQL:2023 — was reverted on September 7, removing 47 commits: the entire feature plus every fix built on top of it since it landed.

Tom Lane, one of PostgreSQL's longest-tenured contributors, put the risk plainly on the mailing list: "At this point I'd be willing to bet dinner that if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20." Tom Kincaid, EDB's senior VP of software engineering, publicly confirmed PGQ would not be part of the 19 release. The trade press covered it as a story about restraint — The Register's headline framed it as the feature failing "the 'would you ship this?' test" — which is a fair summary of what actually happened: a feature that worked in demos wasn't trusted to work unattended in production for years, so it got pulled rather than shipped and patched later.

Because PostgreSQL major versions are supported for roughly five years and a SQL-surface feature like PGQ is hard to change once applications depend on it, the project's norm is that it's cheaper to delay a feature by a year than to ship something that might need a breaking fix in a point release. The earliest PGQ could now land is PostgreSQL 20, expected around September 2027.

What's still actually in PostgreSQL 19

The revert doesn't erase the rest of the release. Based on the beta release notes, PostgreSQL 19 still includes:

`REPACK`, a new command that folds together what VACUUM FULL and CLUSTER used to do separately — reclaiming disk space and reorganizing table storage — with a CONCURRENTLY option that avoids blocking reads and writes while it runs.
Parallel autovacuum, which can now use multiple worker processes to vacuum a single table's indexes, plus a new pg_stat_autovacuum_scores view that shows which tables autovacuum considers most in need of attention.
Sequence values in logical replication, and the ability to raise wal_level to replica and enable logical replication without a full server restart.
Online toggling of data checksums — turning checksums on or off without taking the server down.
`pg_plan_advice`, a new module for pinning down query plans, and eager aggregation improvements aimed at analytical queries.
Reported gains of up to roughly 2x on insert throughput in workloads with foreign-key checks, per the beta release notes — a vendor/project-reported figure from the release notes themselves, not an independently reproduced benchmark, so treat it as a claim to verify against your own workload rather than a guarantee.

None of that is small. Parallel autovacuum and online REPACK in particular address two of the most common operational headaches in any Postgres-backed production system: vacuum falling behind on large, busy tables, and needing a maintenance window to reclaim bloat. The graph-query removal is the story because it's unusual — features rarely get pulled this late — not because the release is thin without it.

What this changes

For a team running Postgres in production today, close to nothing changes immediately. This site's own stack (src/lib/db.ts, per this repo's CLAUDE.md) runs a Prisma client against Postgres with slow-query logging, and nothing here requires action before PostgreSQL 19 ships. The practical items worth tracking:

If you were planning around SQL/PGQ, drop that plan. It's not in 19, full stop, and won't be until at least PostgreSQL 20 in a year. If you need graph-shaped queries against relational data now, you're still writing recursive CTEs or reaching for a dedicated graph store.
If large-table vacuum lag or bloat-driven maintenance windows are a recurring pain, parallel autovacuum and online REPACK are worth testing against a beta or RC build (Amazon RDS already has PostgreSQL 19 beta 3 in its preview environment) before the version reaches your production upgrade queue.
Read release notes, not headlines, before any major-version upgrade. This cycle is a concrete reminder that beta feature lists change — a feature present in beta 2 was gone by beta 3's successor. Don't design a migration around a not-yet-released capability until it survives to a release candidate.
The process itself is the more durable lesson. A team with commit rights and a beta already in the wild still pulled 47 commits of a marquee, standards-track feature two weeks before likely release, in public, with a named engineer staking a dinner bet on the reasoning. That's a data point on how PostgreSQL's governance treats "works in beta" versus "safe to support for five years" — worth keeping in mind the next time a database migration guide promises a not-yet-GA feature will "just be there."

Wise Hustlers builds and operates production systems on Postgres, including schema, query, and migration work — see our services if that's relevant to your stack.

PostgreSQL 19 Loses Its Headline Feature Weeks Before Release — Here's What Actually Shipped

What happened, in order

What's still actually in PostgreSQL 19

What this changes

Sources

Related articles