PostgreSQL 19 Beta 1: Graph Queries, No Extra Database Required

PostgreSQL 19 Beta 1 landed on June 4. The headline feature is SQL/PGQ — native property graph queries over your existing relational tables. No extra database, no data migration, no graph-database subscription. For developers running a separate Neo4j instance just for follower graphs, tag clustering, or dependency trees, this beta warrants a serious look.

SQL/PGQ: Graph Queries Without Leaving Postgres

SQL/PGQ implements part of the SQL:2023 standard. A property graph is defined as metadata over tables you already have — it is a view, not a new storage engine. You declare which tables are nodes and which are edges, then query graph patterns with the new GRAPH_TABLE construct.

Here is a minimal social graph example:

-- Define the graph once
CREATE PROPERTY GRAPH social_graph
  VERTEX TABLES (
    users LABEL person PROPERTIES (id, name, email),
    posts LABEL post  PROPERTIES (id, title, created_at)
  )
  EDGE TABLES (
    follows
      SOURCE KEY (follower_id) REFERENCES users (id)
      DESTINATION KEY (followed_id) REFERENCES users (id)
      LABEL follows,
    likes
      SOURCE KEY (user_id)  REFERENCES users (id)
      DESTINATION KEY (post_id) REFERENCES posts (id)
      LABEL liked
  );

-- Query: who does Alice follow?
SELECT *
FROM GRAPH_TABLE (social_graph
  MATCH (a IS person WHERE a.name = 'Alice')
        -[IS follows]->
        (b IS person)
  COLUMNS (b.name AS followed_name)
);

The graph definition is pure metadata. The data stays in your existing tables, and Postgres rewrites graph patterns into ordinary joins at query time. There is no second storage layer to synchronize.

One honest limitation in Beta 1: no variable-length paths. You cannot write -[IS follows]->+ for “one or more hops.” Each hop must be written explicitly. Fixed-depth patterns cover most practical use cases — friends-of-friends, direct dependencies, shallow recommendation graphs — but if your workload requires arbitrary-depth traversals, the full graph-database story is not here yet. Variable-length support is planned for a future release. For a detailed breakdown, The Build’s SQL/PGQ deep-dive is the best technical read available.

ON CONFLICT DO SELECT: Atomic Get-or-Create, Finally

PostgreSQL 19 adds a third option to INSERT ... ON CONFLICT: DO SELECT. This gives you atomic get-or-create in a single statement.

The old way required a CTE or two round trips, both prone to race conditions under concurrent load:

-- Old: brittle under concurrency
WITH ins AS (
  INSERT INTO tags (name) VALUES ('postgresql')
  ON CONFLICT (name) DO NOTHING
  RETURNING id
)
SELECT id FROM ins
UNION ALL
SELECT id FROM tags WHERE name = 'postgresql';

The new way:

-- New: one atomic statement
INSERT INTO tags (name)
VALUES ('postgresql')
ON CONFLICT (name) DO SELECT
RETURNING id;

Two constraints to know: RETURNING is required (omitting it is a syntax error), and you must specify a conflict target. If you need to lock the returned row for a follow-up update, add FOR UPDATE:

INSERT INTO jobs (idempotency_key, payload)
VALUES ($1, $2)
ON CONFLICT (idempotency_key) DO SELECT FOR UPDATE
RETURNING *;

This pattern shows up constantly in ORMs, job queues, and API layers. The CTE workaround has been a quiet source of duplicate-row bugs under load. Neon’s ON CONFLICT DO SELECT reference covers the full syntax.

Parallel Autovacuum and Native REPACK

Parallel autovacuum lands in PG19 with a new configuration parameter: autovacuum_max_parallel_workers. The default is zero, which is intentional. Parallel autovacuum only speeds up index cleanup, and only when there are many indexes on the table. VACUUM is I/O-bound; adding parallel workers to a storage-limited setup accomplishes nothing. If you have high-write tables with ten or more indexes on NVMe or fast SSD storage, it is worth testing. For most clusters, leave it at zero.

More immediately useful: the REPACK command is now in core Postgres. The pg_repack extension has been a Postgres ops staple for reclaiming table bloat. Running it natively means:

REPACK TABLE orders CONCURRENTLY;

With CONCURRENTLY, the exclusive lock is held only during the final file swap. The table stays readable and writable for the bulk of the operation. Managed cloud providers that struggled to ship pg_repack as an extension will likely support this faster.

Operational Changes to Check Before Upgrading

JIT (just-in-time compilation) is now off by default. It has been on since PG12. If you run analytic or reporting queries that relied on JIT, they will be slower after upgrading unless you re-enable it. Benchmark before committing to an upgrade.

On the upside: logical replication can now be enabled without a server restart. The new read-only parameter effective_wal_level reports the actual WAL level in effect. Sequence values also auto-sync to logical replicas now, which removes one manual reconciliation step from major-version upgrade procedures.

How to Test and What’s Next

Pull the Docker image and run:

docker run -e POSTGRES_PASSWORD=secret -p 5432:5432 postgres:19beta1

The PostgreSQL project asks for testing on real workloads with real schemas — not just synthetic benchmarks. AWS made Beta 1 available in the RDS Database Preview Environment on June 8, which makes cloud-based testing straightforward. Report bugs through the official PostgreSQL beta testing page.

GA is targeted for September/October 2026. Read the official Beta 1 announcement for the full feature list before you start testing.