Explore PostgreSQL SQL/PGQ adapter for pgGraph

[evokoa-admin]

Summary

PostgreSQL SQL/PGQ introduces standard graph query syntax such as property graphs and graph table queries. pgGraph currently exposes graph functionality through SQL functions in the graph schema.

This issue tracks research and design for whether a future SQL/PGQ-facing adapter could map PostgreSQL graph syntax onto pgGraph's existing runtime engine.

Why this matters

pgGraph is optimized as a graph execution layer over ordinary PostgreSQL tables. SQL/PGQ could provide a more familiar standards-based query surface while still using pgGraph's CSR-backed traversal engine underneath.

We've had a lot of inbound community requests for this feature. So we want to ship it sometime next week.

Scope

This is a design/research issue, not an implementation issue yet.

Investigate:

• What SQL/PGQ concepts map cleanly to pgGraph's current table and edge registration model
• Whether CREATE PROPERTY GRAPH metadata can map to existing graph.add_table, graph.add_edge, or discovery APIs
• Which query shapes could map to existing pgGraph APIs:
  • bounded traversal
  • shortest path
  • weighted shortest path
  • path reconstruction
  • source search
• Which SQL/PGQ features do not currently fit pgGraph's model
• Whether an adapter should be implemented inside pgGraph or kept as documentation/examples first

Non-goals

• Do not implement a separate graph database
• Do not replace PostgreSQL as the source of truth
• Do not add a second storage model
• Do not degrade existing SQL function APIs