Plans to support PostgreSQL 18 native SQL/PGQ (Property Graph Queries) as a graph backend?

[saintd]

Hello LightRAG team!

PostgreSQL 18 (scheduled for release in September 2025) introduces native support for SQL Property Graph Queries (SQL/PGQ) via the SQL:2023 standard. This feature enables graph traversals directly within PostgreSQL using syntax like GRAPH_TABLE, eliminating the need for extensions.

Given LightRAG's existing support for Apache AGE as a graph_storage backend:

1. Integration Plans: Are there intentions to add PostgreSQL 18 SQL/PGQ as a new backend option?
2. Long-term Viability: Could SQL/PGQ eventually replace Apache AGE, especially considering AGE's lack of PostgreSQL 17+ compatibility and uncertain roadmap?

Would love to hear your perspective on whether SQL/PGQ aligns with LightRAG's future direction.

[onestardao]

great question — SQL/PGQ definitely looks promising as a native alternative, and it's exciting that it's now part of the SQL:2023 standard. that said, there are two caveats worth surfacing early:

Execution Planning: PGQ semantics (esp. recursive graph traversals via GRAPH_TABLE) may behave very differently under PostgreSQL’s query planner compared to AGE’s dedicated traversal engine. this could impact runtime predictability for large/heterogeneous graphs — which matters if you’re mixing subgraph retrieval with RAG-style indexing.

Control Granularity: some edge annotation and traversal patterns (e.g., weighted hops, semantic filters) that were possible via AGE’s cypher subset might not be as expressive under vanilla PGQ yet. depends on your use case — but for hybrid AI pipelines, this limitation can sneak up on you.

so yeah — PGQ might be a cleaner long-term path, but worth sanity-checking how much reasoning fidelity you'd be trading off before jumping ship from AGE.