PostgreSQL to pull property graphs from v19 after design flaws

PostgreSQL will strip the new SQL/PGQ property graph feature from the upcoming 19 release after core developers found systemic locking, dependency, and catalog problems that leave graphs crash-prone, undumpable, and inconsistent under ordinary DDL.

Andres Freund raised the alarm after inspecting dump and dependency handling. Property graphs sat awkwardly in the catalog (including needless attribute rows), pg_dump missed dependencies such as property types, and cascade drops of underlying tables left orphaned labels and properties. Those leftovers later blocked legitimate ALTER PROPERTY GRAPH commands with spurious type-mismatch errors and could make a graph unrestorable.

Melanie Plageman, writing for the Release Management Team, summarized unresolved design questions: orphan cleanup is only a stop-gap, global versus per-label label and property scoping still lacks consensus, and several correct fixes would need dependency machinery too invasive for 19. Freund then reported further defects found in a short manual pass and with automated review: rewrite paths that read element-table schemas without locks, AlterPropGraph taking locks too weak to block concurrent rewrites, out-of-bounds reads on unknown types, whole-row GRAPH_TABLE references that expand to zero columns, missing privilege checks, and dump breakage on whole-row property expressions.

Other developers added failures around DROP OWNED BY, silent loss of graphs whose edge keys came from foreign keys, non-unique keys accepted contrary to the documentation, and column type changes that error on property dependencies. Sami Imseih objected to teaching generic deletion code property-graph-specific orphan logic, calling it compensation for unclean catalog representation.

Freund concluded the feature is nowhere near ready for 19 and may not be ready to remain in 20. Peter Eisentraut agreed to the revert, asking only whether it should apply solely to the 19 stable line or to master as well. The move removes release pressure and lets the project redesign dependency and locking behavior without compatibility constraints.