On 16th of March 2026, Peter Eisentraut committed patch:
SQL Property Graph Queries (SQL/PGQ) Implementation of SQL property graph queries, according to SQL/PGQ standard (ISO/IEC 9075-16:2023). This adds: - GRAPH_TABLE table function for graph pattern matching - DDL commands CREATE/ALTER/DROP PROPERTY GRAPH - several new system catalogs and information schema views - psql \dG command - pg_get_propgraphdef() function for pg_dump and psql A property graph is a relation with a new relkind RELKIND_PROPGRAPH. It acts like a view in many ways. It is rewritten to a standard relational query in the rewriter. Access privileges act similar to a security invoker view. (The security definer variant is not currently implemented.) Starting documentation can be found in doc/src/sgml/ddl.sgml and doc/src/sgml/queries.sgml. Author: Peter Eisentraut <peter@eisentraut.org> Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Reviewed-by: Junwang Zhao <zhjwpku@gmail.com> Reviewed-by: Ajay Pal <ajay.pal.k@gmail.com> Reviewed-by: Henson Choi <assam258@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/a855795d-e697-4fa5-8698-d20122126567@eisentraut.org
To be honest I somehow missed it. But recently(ish) I saw blogposts about it, and it made me do some research.
Then I tried to do the research. And I just don't get it. From where I sit it's extra language that wraps easy joins in some symbolic language for no apparent (to me) reason.
Don't get me wrong – the problem lies in me, and my understanding, but I just can't get excited about it.
Instead of usual:
select count(*) from knows k1 join knows k2 on k1.b = k2.a where k1.a = 42;
we're supposed to write:
SELECT count(*) FROM GRAPH_TABLE(big_social MATCH (a IS person WHERE a.id = 42)-[IS knows]->(b IS person)-[IS knows]->(c IS person) COLUMNS (c.id));
While I do, kinda, understand the syntax, it will probably take non-trivial time to get used to it, and, at the moment, benefits escape me.
Maybe because of things that will get added to it in the future, that will make writing certain types of queries easier?
Anyway, since I clearly don't grok it yet, I'll point you instead to series of blogposts from CYBERTEC:
- Handling graphs with SQL/PGQ in PostgreSQL
- Heterogeneous Graphs in SQL/PGQ on PostgreSQL 19
- How SQL/PGQ Rewrites to Joins on PostgreSQL 19
- Data Lineage in PostgreSQL 19: Finally, an Answer When the CFO Asks “Where Did This Number Come From?"
In any way, regardless of my personal problems with understanding, I know it's a big deal, so I'd like to thank everybody involved. And perhaps someone can point me to some source of information about “why I should get more enthusiastic about it"…
I have same feeling. On second hand, for the task (and data) that are naturally based on graphs, this syntax can better readable. Using joins in these cases hides natural mathematical model.