PostgreSQL 19 graph queries fail the 'would you ship this?' test
- ID
- 24639
- Status
- summarized
- Published
- 15 Sep 2026, 5:42 PM
- Fetched
- 15 Sep 2026, 9:26 PM
- Provider
- The Register
- Category
- technology
- Original URL
- https://www.theregister.com/databases/2026/09/15/postgresql-19-graph-queries-fail-the-would-you-ship-this-test/5296343
- Source URL
- https://www.theregister.com/headlines.atom
Summary
- Score
- 7.0
- Created
- 15 Sep 2026, 9:27 PM
- Tags
- Audience
- developersdatabase_learners
What happened
PostgreSQL developers removed SQL Property Graph Queries (SQL/PGQ) from version 19 over unresolved bugs, with contributor Tom Lane warning that shipping it would likely lead to post-release bugs unfixable until v20. A fourth beta is scheduled for September 24, with the release date still unconfirmed. Meanwhile, version 19 introduces a REPACK command with a CONCURRENTLY option that lets other transactions access a table during most of the operation, replacing the need for VACUUM FULL's exclusive table lock.
Why it matters
If you were waiting for SQL/PGQ graph queries in Postgres 19, stop planning around it—it's been pulled and won't arrive until at least v20. More practically, the new REPACK CONCURRENTLY command means you can reclaim disk space without blocking reads and writes for the full duration, which directly reduces downtime windows for maintenance on production Postgres instances.
Discussion angle
Whether the REPACK CONCURRENTLY command is enough to retire VACUUM FULL workflows in production, and what the SQL/PGQ delay means for teams who were planning to use Postgres for graph-style relationship queries instead of adopting a separate graph database.