PGConf.dev 2026 Graph Database Developer Meeting

From PostgreSQL wiki
Jump to navigationJump to search

WIP:

Minutes of graph database developer meeting.

Thanks Henson Choi for providing detailed notes of the discussions in the meeting.

Goal and Agenda

  • Discuss the priorities of features in SQL/PGQ to be implemented next
  • Discuss symbiosis of Apache/AGE (and other such extensions) and SQL/PGQ
  • Discuss implementation of some priority features if time permits.

Meeting summary

Future development

We committed basic SQL/PGQ support to PG 19. It covers most of the DDL and basic support for graph query constructs. Developers are welcome to enhance the query support further. They are encouraged to write patches, review and test them. We would like more developers, beyond the initial set of authors and reviewers, to get involved in this effort. Features that implement specifications from SQL/PGQ standard have high chances of being accepted. Implementing improvements outside SQL/PGQ is not prohibited, but will get a secondary priority.

The graph query syntax supported in PG 19 supports basic path pattern constructs like label expression, WHERE clause in element pattern and path pattern, COLUMNs clause, implicit edge and vector patterns etc. Supporting quantified element patterns aka variable length edge (VLE) patterns (e.g. -[]->{m, n}) will be required to make this feature minimally useful. Many of the graph database applications require this feature. Some detailed specifications like bounded vs unbounded path and whether to implement it as recursive CTE or unions over joins remains to be finalized.

For any feature, measuring its performance and comparing it against graph database systems like neo4j will be important. Given that SQL/PGQ is implemented on top of relational database, we can not expect it its performance to be at par with native graph databases. But it should be closer (withing 50%) to native graph database systems.

Graph database specific enhancements

Features like CSR (compressed sparse row) index and special executor nodes for SHORTEST path implementation were discussed briefly. Since SQL/PGQ is implemented as a translation layer from graph query to SQL, if these features improve performance of SQL/PGQ constructs, they might be able to improve performance of the corresponding SQL constructs. They have high chance of acceptance if they can be used outside SQL/PGQ as well e.g. to improve performance of foreign key joins.


Thanks Henson Choi for providing detailed notes of the discussions in the meeting.

Retrieved from "https://wiki.postgresql.org/index.php?title=PGConf.dev_2026_Graph_Database_Developer_Meeting&oldid=43516"