Overview of SQL/PGQ in PostgreSQL by CYBERTEC

• From: Saqib Ali | Date: Wed, 03 Jun 2026 20:18:30 +0000 #
  Subject: Overview of SQL/PGQ in PostgreSQL by CYBERTEC

  An excellent blogpost on support for SQL/PGQ in Postgres 19 by CYBERTEC: https://www.cybertec-postgresql.com/en/handling-graphs-with-sql-pgq-in-postgresql/ Sample query from the blogpost for handling multiple hops in Postgres 19: SELECT * FROM GRAPH_TABLE (social MATCH (a IS person)-[IS knows]->(b IS person)-[IS knows]->(c IS person) COLUMNS (a.name AS a, b.name AS mutualfriend, c.name AS c) ) ORDER BY a, c, mutualfriend

  [ Reply ]
  • |-- Reply
    From: Stephanie Tran | Date: Wed, 17 Jun 2026 02:33:51 +0000 #

    I am loving the the SQL/PGQ support in Postgres 19. We have used it in Oracle for while now. Some key technical points Graph modeling without extensions SQL/PGQ lets you declare a graph using existing relational tables via: CREATE PROPERTY GRAPH ... This maps tables (e.g., person, knows) into: Vertices (nodes) Edges (relationships) Graph queries using SQL MATCH SQL/PGQ adds a MATCH clause to SQL, enabling pattern-based graph traversal. Examples include: Multi-hop traversal (friends-of-friends) Restrictions Variable-length path (quantified path pattern) e.g. (a)-[:FRIEND]->{1,}(b) is currently not supported SELECT * is not allowed inside graph pattern queries. Queries must explicitly reference projected fields. Execution model PostgreSQL internally transpiles graph queries into standard SQL. Directional edges and graph patterns are converted into joins and filters. The user writes graph logic; PostgreSQL handles the relational translation. Query correctness still depends on SQL semantics WHERE clauses still apply after the MATCH clause. Filtering and projection behave like normal SQL.

    [ Reply ]