<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/what-s-coming-in-postgresql-19-graph-queries-checkpoint-control-and-beta-2-fixes-ffxnyuzfk" -->

---
title: What&#x27;s coming in PostgreSQL 19: graph queries,...
description: PostgreSQL 19 Beta 2 is now available, with general availability expected around September–October 2026. The headline feature is SQL/PGQ, a standardized ISO...
canonical: https://daily.dev/posts/what-s-coming-in-postgresql-19-graph-queries-checkpoint-control-and-beta-2-fixes-ffxnyuzfk
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: What&#x27;s coming in PostgreSQL 19: graph queries, checkpoint control, and beta 2 fixes | daily.dev
og:description: PostgreSQL 19 Beta 2 is now available, with general availability expected around September–October 2026. The headline feature is SQL/PGQ, a standardized ISO...
og:url: https://daily.dev/posts/what-s-coming-in-postgresql-19-graph-queries-checkpoint-control-and-beta-2-fixes-ffxnyuzfk
og:image: https://api.daily.dev/og/posts/fFxnYUzfk.png
og:image:alt: What&#x27;s coming in PostgreSQL 19: graph queries, checkpoint control, and beta 2 fixes
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# What's coming in PostgreSQL 19: graph queries, checkpoint control, and beta 2 fixes

**[Collections](https://daily.dev/sources/collections)** · 3 min read · 14 upvotes · 1 comments

## Summary

PostgreSQL 19 Beta 2 is now available, with general availability expected around September–October 2026. The headline feature is SQL/PGQ, a standardized ISO syntax for querying graph-shaped data directly in Postgres by defining property graphs as views over existing tables. Queries are rewritten to regular SQL joins, making it suitable for authorization graphs, org hierarchies, and dependency trees — but not a replacement for native graph databases like Neo4j for deep traversal workloads. Variable-length path traversal is not yet supported. The release also extends the CHECKPOINT command with MODE FAST (existing behavior), MODE SPREAD (paced writes to reduce I/O spikes), and a FLUSH_UNLOGGED option for forcing dirty buffers from unlogged tables to disk. Beta 2 also includes fixes for vacuumdb, pg_createsubscriber, temporal table syntax, and postgres_fdw foreign-table statistics handling.

## Content

PostgreSQL 19 is shaping up to be a genuinely interesting release. Beta 2 is out now, with general availability expected around September or October 2026. Here's what's worth paying attention to.

## Property graph queries (SQL/PGQ)

The headline feature is SQL/PGQ — a standardized ISO syntax for querying graph-shaped data directly inside Postgres, without a separate graph database.

The way it works: you define a property graph as a read-only view over existing tables, declaring which tables act as vertices and which as edges. Then you query them using an arrow-syntax match pattern that will feel familiar if you've used Neo4j's Cypher.

Under the hood, graph queries are rewritten to regular SQL joins. That means your existing indexes and security models apply automatically. It also means you don't get index-free adjacency — the performance characteristic that makes native graph databases fast for deep traversal over massive connected datasets. If that's your workload, Neo4j is still the right tool.

What SQL/PGQ is actually good for: authorization graphs, org hierarchies, dependency trees, fraud investigation queries — cases where the graph structure supplements relational data rather than replacing it. The real competition here isn't Neo4j. It's the recursive CTEs developers have been writing for years to do this same work, badly.

One current limitation: only fixed-depth pattern matching is supported. Variable-length path traversal is planned for a future version.

## Checkpoint control

Postgres 19 extends the `CHECKPOINT` command with a new parenthesized option syntax and two new modes.

`MODE FAST` preserves the existing behavior — an immediate full flush. `MODE SPREAD` paces writes over a longer window using `checkpoint_completion_target` and `checkpoint_timeout`, which avoids the I/O spikes that can hit busy servers during a checkpoint. In benchmarks, `MODE SPREAD` took over two minutes on a 517MB dataset versus around 400ms for `MODE FAST` — so it's not faster, it's just less disruptive to concurrent workloads.

There's also a new `FLUSH_UNLOGGED` option, which forces dirty buffers from unlogged tables to disk. Normally that only happens at clean shutdown, so this gives operators more control over durability for unlogged tables when they need it.

One thing to know: when concurrent checkpoint requests collide, Postgres consolidates them using the most urgent attributes. So these options are preferences, not guarantees. Automatic background checkpoints are unaffected.

## Beta 2 fixes

Beta 2 includes a range of smaller fixes: improvements to `vacuumdb --analyze-in-stages` for partitioned tables, fixes to `pg_createsubscriber`, REPACK worker cleanup on FATAL exit, `FOR PORTION OF` temporal table syntax, `max_retention_duration`, `md5_password_warnings`, `pg_dumpall`, `ALTER DOMAIN ... VALIDATE CONSTRAINT`, and `postgres_fdw` handling of imported foreign-table statistics.

The usual advice applies: test it against your workloads, report bugs, don't run it in production.

## Questions this post answers

### What is SQL/PGQ in PostgreSQL 19 and how does it work?

SQL/PGQ is a standardized ISO syntax added in PostgreSQL 19 for querying graph-shaped data directly inside Postgres. You define a property graph as a read-only view over existing tables, declaring which tables act as vertices and edges, then query using Cypher-like arrow-syntax match patterns. Queries are rewritten into regular SQL joins, so existing indexes and security models apply automatically, but only fixed-depth pattern matching is supported so far.

_Teams weighing graph queries in Postgres versus a dedicated graph database can track this feature's evolution on daily.dev._

### Does PostgreSQL's SQL/PGQ replace the need for Neo4j?

No, SQL/PGQ does not provide index-free adjacency, the performance characteristic that makes native graph databases like Neo4j fast for deep traversal over massive connected datasets. It's best suited for cases where graph structure supplements relational data, such as authorization graphs, org hierarchies, dependency trees, and fraud investigation queries, rather than replacing a dedicated graph database entirely.

_Anyone deciding between Postgres and a graph database for a given workload can follow this comparison on daily.dev._

### What does the new CHECKPOINT MODE SPREAD option do in PostgreSQL 19?

MODE SPREAD paces checkpoint writes over a longer window using checkpoint_completion_target and checkpoint_timeout, avoiding I/O spikes on busy servers, unlike MODE FAST which does an immediate full flush. In benchmarks on a 517MB dataset, MODE SPREAD took over two minutes versus about 400ms for MODE FAST, trading speed for less disruption to concurrent workloads. A FLUSH_UNLOGGED option was also added to force dirty buffers from unlogged tables to disk on demand.

_DBAs tuning checkpoint behavior for production workloads can track PostgreSQL 19 changes like this on daily.dev._

## Community discussion

Top comments from developers on daily.dev.

**@idoshamun** · 0 upvotes

> Postgres is keep eating the world. The graph query definitely opens the door to many more use cases

## Similar posts on daily.dev

- [PostgreSQL 19 Beta Introduces SQL Graph Queries and Concurrent Table Repacking](https://daily.dev/posts/postgresql-19-beta-introduces-sql-graph-queries-and-concurrent-table-repacking-2adopzbmz) · InfoQ · 91 upvotes · 4 comments

---

Tags: [#backend](https://daily.dev/tags/backend), [#postgresql](https://daily.dev/tags/postgresql)

[View this post on daily.dev](https://daily.dev/posts/what-s-coming-in-postgresql-19-graph-queries-checkpoint-control-and-beta-2-fixes-ffxnyuzfk)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"What's coming in PostgreSQL 19: graph queries, checkpoint control, and beta 2 fixes","url":"https://daily.dev/posts/what-s-coming-in-postgresql-19-graph-queries-checkpoint-control-and-beta-2-fixes-ffxnyuzfk","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/what-s-coming-in-postgresql-19-graph-queries-checkpoint-control-and-beta-2-fixes-ffxnyuzfk"},"datePublished":"2026-07-17T11:50:45.755Z","dateModified":"2026-09-13T19:37:13.402Z","description":"PostgreSQL 19 Beta 2 is now available, with general availability expected around September–October 2026. The headline feature is SQL/PGQ, a standardized ISO...","image":"https://postgr.es/static/images/pgEdge-favicon.webp","thumbnailUrl":"https://postgr.es/static/images/pgEdge-favicon.webp","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/what-s-coming-in-postgresql-19-graph-queries-checkpoint-control-and-beta-2-fixes-ffxnyuzfk","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":14},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"backend,postgresql","timeRequired":"PT3M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"What's coming in PostgreSQL 19: graph queries, checkpoint control, and beta 2 fixes"}]}
{"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/what-s-coming-in-postgresql-19-graph-queries-checkpoint-control-and-beta-2-fixes-ffxnyuzfk","comment":[{"@type":"Comment","text":"Postgres is keep eating the world. The graph query definitely opens the door to many more use cases","datePublished":"2026-07-19T06:07:32.395Z","url":"https://daily.dev/posts/fFxnYUzfk#c-uP3a7CUgG","author":{"@type":"Person","name":"Ido Shamun","url":"https://daily.dev/idoshamun","image":"https://media.daily.dev/image/upload/s---xy_OAwk--/f_auto,q_auto/v1703781380/avatars/avatar_28849d86070e4c099c877ab6837c61f0"}}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/what-s-coming-in-postgresql-19-graph-queries-checkpoint-control-and-beta-2-fixes-ffxnyuzfk#faq","mainEntity":[{"@type":"Question","name":"What is SQL/PGQ in PostgreSQL 19 and how does it work?","acceptedAnswer":{"@type":"Answer","text":"SQL/PGQ is a standardized ISO syntax added in PostgreSQL 19 for querying graph-shaped data directly inside Postgres. You define a property graph as a read-only view over existing tables, declaring which tables act as vertices and edges, then query using Cypher-like arrow-syntax match patterns. Queries are rewritten into regular SQL joins, so existing indexes and security models apply automatically, but only fixed-depth pattern matching is supported so far. Teams weighing graph queries in Postgres versus a dedicated graph database can track this feature's evolution on daily.dev."}},{"@type":"Question","name":"Does PostgreSQL's SQL/PGQ replace the need for Neo4j?","acceptedAnswer":{"@type":"Answer","text":"No, SQL/PGQ does not provide index-free adjacency, the performance characteristic that makes native graph databases like Neo4j fast for deep traversal over massive connected datasets. It's best suited for cases where graph structure supplements relational data, such as authorization graphs, org hierarchies, dependency trees, and fraud investigation queries, rather than replacing a dedicated graph database entirely. Anyone deciding between Postgres and a graph database for a given workload can follow this comparison on daily.dev."}},{"@type":"Question","name":"What does the new CHECKPOINT MODE SPREAD option do in PostgreSQL 19?","acceptedAnswer":{"@type":"Answer","text":"MODE SPREAD paces checkpoint writes over a longer window using checkpoint_completion_target and checkpoint_timeout, avoiding I/O spikes on busy servers, unlike MODE FAST which does an immediate full flush. In benchmarks on a 517MB dataset, MODE SPREAD took over two minutes versus about 400ms for MODE FAST, trading speed for less disruption to concurrent workloads. A FLUSH_UNLOGGED option was also added to force dirty buffers from unlogged tables to disk on demand. DBAs tuning checkpoint behavior for production workloads can track PostgreSQL 19 changes like this on daily.dev."}}]}
```

