PostgreSQL 19 Beta 2: Native Graph Queries and REPACK

PostgreSQL 19 Beta 2 landed July 16 with feature freeze locked in — what you see is what ships to general availability this September or October. Four features stand out: native graph queries on your relational tables, a zero-downtime table rebuild command, parallel autovacuum, and live checksum toggling. If you run Postgres in production, at least one of these is going to change how you work.

SQL/PGQ: Graph Queries, No Separate Database Required

The headline feature is SQL/PGQ — PostgreSQL’s implementation of ISO SQL:2023 Part 16. The standard gives you two constructs: CREATE PROPERTY GRAPH defines a graph view over existing relational tables, and GRAPH_TABLE with MATCH lets you query it using pattern-matching syntax. Internally, it rewrites to standard relational joins and uses your existing indexes.

What this actually means: if you’re running Neo4j or Apache AGE alongside Postgres to handle graph-shaped queries — social follows, dependency trees, org hierarchies, recommendation engines — you may not need a separate system anymore. The graph and relational layers share the same planner, the same executor, and the same transaction context. You can mix graph and SQL queries in a single statement, something no Postgres+Neo4j architecture can match.

Here’s what the setup looks like for a simple social graph:

CREATE PROPERTY GRAPH social_graph
  VERTEX TABLES (users LABEL person PROPERTIES (id, name))
  EDGE TABLES (
    follows
      SOURCE KEY (follower_id) REFERENCES users (id)
      DESTINATION KEY (followed_id) REFERENCES users (id)
      LABEL follows
  );

And a friends-of-friends query:

SELECT * FROM GRAPH_TABLE (social_graph
  MATCH
    (a IS person WHERE a.name = 'Alice')
    -[IS follows]->(b IS person)
    -[IS follows]->(c IS person)
  COLUMNS (b.name AS friend, c.name AS friend_of_friend)
);

The honest caveats: v19’s SQL/PGQ is read-only, and it only handles fixed-depth traversal. Variable-length paths — the + and * quantifiers you’d need for arbitrary-depth graph walks — are scheduled for a future release. If graph queries are your core product, Neo4j is still the right tool. But the ‘you need a dedicated graph database’ argument just got significantly harder to make for every other use case.

REPACK CONCURRENTLY: The Maintenance Window Killer

Table bloat is an unavoidable reality in high-update Postgres deployments. The traditional fix — VACUUM FULL or CLUSTER — holds an ACCESS EXCLUSIVE lock for its entire run. On large tables, that means planned downtime, which means scheduled maintenance windows, which means your on-call rotation gets involved.

PostgreSQL 19 adds REPACK with a CONCURRENTLY mode that changes this entirely. It copies the table to a fresh heap, uses logical decoding to replay any concurrent writes during the copy, then holds the exclusive lock only for the final file swap — typically seconds. The table stays readable and writable for the bulk of the operation.

The pg_repack extension has done this for years, but it required extension management, version compatibility tracking, and trust in a third-party package. REPACK CONCURRENTLY is now in core. One caveat: it builds a full table copy, so you need adequate disk headroom before running it against large tables.

Method	Lock Duration	Online?	In Core?
VACUUM FULL	Entire run	No	Yes
pg_repack (extension)	Brief final swap	Yes	No
REPACK CONCURRENTLY	Brief final swap	Yes	Yes (v19)

Parallel Autovacuum and Online Checksums

Two more operational improvements that ship in v19:

Parallel autovacuum. Large tables with multiple large indexes were vacuumed one index at a time. New GUCs — autovacuum_max_parallel_workers globally and autovacuum_parallel_workers per table — let autovacuum run multiple workers in parallel. If autovacuum has been falling behind on your largest tables, this is the fix you’ve been waiting for.

Online checksums. Two new functions — pg_enable_data_checksums() and pg_disable_data_checksums() — toggle data integrity checking on a live, running cluster. Previously this required stopping the cluster entirely. Teams that skipped checksums at cluster init can now enable them without a maintenance window.

What to Do Before GA

Feature freeze is set. The PostgreSQL team is asking for beta testers running production-like workloads — bugs filed now directly shape what ships to GA. Download Beta 2, spin it up against a copy of your staging environment, and run your workloads through it. Pay particular attention to SQL/PGQ if you have any graph-shaped data, and to REPACK CONCURRENTLY if you manage tables with significant bloat.

GA is expected September or October 2026. The full feature and breaking-changes list is in the official release notes.