The feature PostgreSQL 19 could not keep

On September 7, 2026, Peter Eisentraut pushed two commits titled "Revert SQL Property Graph Queries (SQL/PGQ)": one to master and one to REL_19_STABLE. The master commit touches 125 files, adds 77 lines and deletes 15,857. Its message lists 47 commits being undone, starting with the original feature commit and running through every fix layered on it since: collation, LATERAL references, pg_dump ACLs, stack overflow checks, "Prohibit locking clauses on GRAPH_TABLE", "Prohibit GRANT ... ON TABLE on a property graph". The release-branch commit lists 49. CREATE PROPERTY GRAPH and GRAPH_TABLE will not be in PostgreSQL 19.

The PostgreSQL 19 open items page now shows Beta 4 on September 24 and RC1 and GA as "TBD". The project's roadmap page still says "This release is planned for September 2026." Those two statements will not both survive the month.

A contest nobody wanted to win

The thread that led here opened on August 25 under the subject "scary patch contest". Robert Haas wrote: "I asked Claude to evaluate which v19 patches were the scariest based on the number and type of bugs fixed post-freeze." The resulting list had six entries, ranked by fixes since the April 8 feature freeze: RI fast-path foreign key checks, REPACK, online data checksums, UPDATE/DELETE FOR PORTION OF, SQL/PGQ, and postgres_fdw statistics import. Property graphs sat fifth with 17 fixes, characterized as "wrong collation, unresolved literals, broken LATERAL references, deparse and pg_dump ACL bugs, plus a series of after-the-fact prohibitions".

Haas's stated worry was the top three, not the graphs. Tom Lane disagreed about where the danger was: "FWIW, I am quite afraid of #5, mainly because we are still discussing fixes that will require parsetree and/or catalog changes and thus catversion bumps... 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." Haas came around on that point: "I don't think features that may need catversion bumps belong in v19 at this point... the time for working out what the catalogs should look like was sometime well in advance of feature freeze, not four months after it."

Andres Freund added the threat model. For FOR PORTION OF and PGQ, he wrote, the risk is high "due to the broad exposure to users... an attacker doing something intentionally adverse is possible with relatively low privileges". Melanie Plageman stated the principle the release team would act on a week later: "The unsatisfactory state of alternatives is not a reason to ship code in core Postgres that we don't feel is ready".

The RMT puts on its hat

On September 2, in the PGQ catalog representation thread, Plageman wrote as the release management team. The message is specific about what was unresolved. External DROP TABLE ... CASCADE could "leave orphan graph metadata" that shows up "as phantom entries in information_schema views" and "can render the graph undumpable/unrestorable"; a patch posted the day before was "considered a stop-gap measure and not the ideal fix." Dropping a label or property from one element could leave "a view over a GRAPH_TABLE" "silently unqueryable" when the property still existed elsewhere, with the correct behavior "pending an interpretation of the standard". Whether a property graph should have a pg_class entry at all was still open, and a reported bug where AlterPropGraph() did not verify its target was a property graph looked "indicative of more problems". And there was "the unresolved dependency loop in pg_dump when materialized view queries a GRAPH_TABLE."

Her conclusion: "We feel that if any desired behavior is still unsettled, there is insufficient time to fix these in time for the release." And: "we feel it would be better to revert this in 19. That would take off the time pressure now and would make it easier to fix these things properly in 20 without having to be burdened by backwards compatibility and backpatching."

The replies did not argue the other side. Freund, the same evening: "I concur, this isn't ready for v19. And I think it might not be ready to stay in 20 either." His follow-ups attached SQL reproducers for out-of-bounds reads and crashes on whole-row references. Haas, on September 3, on constraints that were checked at creation time and never maintained afterward: "To me, this class of problem seems completely unacceptable in a committed feature." Eisentraut, the committer of the original feature, answered the same day: "Ok, let's do it." His one question was scope: "Revert from REL_19_STABLE only, or also from master?" Haas: "IMHO, this needs enough rework that it should come out of both." On September 7 Eisentraut posted one word, "done", and the two commits above landed.

What it means for the other five

We feel that if any desired behavior is still unsettled, there is insufficient time to fix these in time for the release.

Melanie Plageman, for the PostgreSQL 19 release management team

Two things are worth taking from this beyond the graph feature itself.

First, the test the RMT applied was not bug count. It was whether the desired behavior was agreed. Seventeen fixes was survivable; an open question about what DROP FUNCTION ... CASCADE should do to a property shared by two labels was not, because a wrong answer would be frozen into the catalog and carried by every future version. That is the standard the remaining five features on Haas's list are being held to. The open items page, at the time of reading, still tracked issues against REPACK, FOR PORTION OF, the RI fast-path and online checksums, and listed the MERGE/SPLIT PARTITION work as already reverted.

Second, the tooling. Haas used Claude to rank the patches. In the PGQ thread, Zsolt Parragi listed eight further unreported problems from a cross-check analysis and noted that "even if some of them end up being false reports, the number of them itself is significant". Whether model-assisted review is finding more bugs, or whether the features were committed too raw, is a question the thread raises and does not settle. What it did settle is that the findings were treated as findings, reproduced, and acted on inside a week.

For anyone who built against the Beta 1 through Beta 3 documentation: the graph DDL disappears in Beta 4. The earliest it can come back is PostgreSQL 20, and Freund's "might not be ready to stay in 20 either" is the sentence to keep in mind when reading next year's release notes.

Primary sources: Revert commit on master, Revert commit on REL_19_STABLE, RMT message and thread, "scary patch contest" thread, PostgreSQL 19 Open Items, PostgreSQL roadmap, read 2026-09-11.