<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/sql-pgq-in-postgres-19-is-clever-but-the-syntax-might-kill-it-0iynuohlk" -->

---
title: SQL/PGQ in Postgres 19 is clever, but the syntax might...
description: PostgreSQL 19 is introducing SQL Property Graph Queries (SQL/PGQ), implementing the ISO/IEC 9075-16:2023 standard. The feature lets you declare property graphs...
canonical: https://daily.dev/posts/sql-pgq-in-postgres-19-is-clever-but-the-syntax-might-kill-it-0iynuohlk
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: SQL/PGQ in Postgres 19 is clever, but the syntax might kill it | daily.dev
og:description: PostgreSQL 19 is introducing SQL Property Graph Queries (SQL/PGQ), implementing the ISO/IEC 9075-16:2023 standard. The feature lets you declare property graphs...
og:url: https://daily.dev/posts/sql-pgq-in-postgres-19-is-clever-but-the-syntax-might-kill-it-0iynuohlk
og:image: https://api.daily.dev/og/posts/0IynuoHLk.png
og:image:alt: SQL/PGQ in Postgres 19 is clever, but the syntax might kill it
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.

# SQL/PGQ in Postgres 19 is clever, but the syntax might kill it

**[Trends](https://daily.dev/sources/trends)** · 2 min read · 16 upvotes · 0 comments

## Summary

PostgreSQL 19 is introducing SQL Property Graph Queries (SQL/PGQ), implementing the ISO/IEC 9075-16:2023 standard. The feature lets you declare property graphs and query them using a GRAPH_TABLE function with pattern-matching syntax for traversing nodes and edges. While there's a genuine use case — particularly for data lineage in analytics pipelines — the syntax is more verbose than equivalent JOIN-based SQL for most queries. A notable limitation is the lack of variable-length path support, meaning deep graph traversal still requires recursive CTEs. The feature is standards-compliant and solves real problems like lineage tracking and dependency graphs, but its verbosity and missing capabilities may limit adoption to specific use cases rather than general graph querying.

## Content

PostgreSQL 19 is shipping SQL Property Graph Queries (SQL/PGQ), implementing the ISO/IEC 9075-16:2023 standard. The short version: you can now declare property graphs in your database and query them with a `GRAPH_TABLE` function instead of chaining joins. The longer version is that people have feelings about this.

The author of the "Waiting for PostgreSQL 19" writeup doesn't hide their skepticism. The new syntax is verbose. For queries that a few well-placed JOINs already handle cleanly, SQL/PGQ reads like a step sideways at best. That's a fair criticism — graph query languages tend to shine when your data is genuinely graph-shaped, and most relational schemas aren't.

But the CYBERTEC data lineage post makes the strongest case for why this matters. The pitch: when your CFO asks where a revenue number came from, you currently have no clean answer. ETL pipelines are implicit, audit trails are bolted on, and tracing a report value back to raw source events means either custom tooling or a lot of manual digging. SQL/PGQ changes that. Model your pipeline relationships as edge tables, declare a property graph, and suddenly you can query lineage directly in SQL — no external graph database, no separate lineage tool, no context switching.

The walkthrough is concrete: an e-commerce analytics pipeline where you can trace any aggregated metric back to its source events, identify what breaks downstream when a schema changes, and surface orphaned data. That's genuinely useful, and it's the kind of thing that's been awkward in relational databases forever.

The honest limitation: SQL/PGQ in Postgres 19 doesn't support variable-length path queries yet. Deep chains still need recursive CTEs, which somewhat undercuts the "graph queries are simpler" argument for complex traversals.

So where does that leave things? SQL/PGQ is a real feature solving a real problem, but the syntax is going to put people off. If your use case is data lineage, dependency tracking, or anything with genuine graph structure, this is worth learning. If you're reaching for it because it's new, you'll probably end up back at JOINs.

## Similar posts on daily.dev

- [SQL/PGQ in PostgreSQL 19: Graph Queries Without the Graph Database](https://daily.dev/posts/sql-pgq-in-postgresql-19-graph-queries-without-the-graph-database-jjw0uthjc) · Planet PostgreSQL · 14 upvotes · 2 comments
- [Handling graphs with SQL/PGQ in PostgreSQL](https://daily.dev/posts/handling-graphs-with-sql-pgq-in-postgresql-nqopnkk2x) · CYBERTEC PostgreSQL · 2 upvotes · 0 comments

---

Tags: [#architecture](https://daily.dev/tags/architecture), [#sql](https://daily.dev/tags/sql), [#postgresql](https://daily.dev/tags/postgresql), [#data-engineering](https://daily.dev/tags/data-engineering)

[View this post on daily.dev](https://daily.dev/posts/sql-pgq-in-postgres-19-is-clever-but-the-syntax-might-kill-it-0iynuohlk)

```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":"SQL/PGQ in Postgres 19 is clever, but the syntax might kill it","url":"https://daily.dev/posts/sql-pgq-in-postgres-19-is-clever-but-the-syntax-might-kill-it-0iynuohlk","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/sql-pgq-in-postgres-19-is-clever-but-the-syntax-might-kill-it-0iynuohlk"},"datePublished":"2026-07-31T17:04:17.288Z","dateModified":"2026-07-31T20:18:11.984Z","description":"PostgreSQL 19 is introducing SQL Property Graph Queries (SQL/PGQ), implementing the ISO/IEC 9075-16:2023 standard. The feature lets you declare property graphs...","isAccessibleForFree":true,"articleSection":"Trends","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":"Trends","logo":"https://media.daily.dev/image/upload/s--ZfSp3asX--/f_auto,q_auto/v1780996004/logos/trends?_a=BAMAMiWQ0","url":"https://daily.dev/sources/trends"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/sql-pgq-in-postgres-19-is-clever-but-the-syntax-might-kill-it-0iynuohlk","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":16},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"architecture,sql,postgresql,data-engineering","timeRequired":"PT2M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Trends","item":"https://daily.dev/sources/trends"},{"@type":"ListItem","position":3,"name":"SQL/PGQ in Postgres 19 is clever, but the syntax might kill it"}]}
```

