Hi everyone,I’m currently refining a GraphRAG architecture on Autonomous Database (26ai) and I’m hitting some interesting trade-offs regarding multi-hop traversal depth and context precision.We are modeling a complex real estate domain where assets (properties) are treated as central nodes within a property graph, linking diverse entities: Users, Interactions, Enterprises, Typologies, and Units.The core challenge is latency management when traversing 4-5 hops in real-time for generative context. We are using GRAPH_TABLE (SQL/PGQ) as our primary query mechanism, which works beautifully for pattern matching directly within our SQL statements.My current query pattern looks roughly like this:
SELECT * FROM GRAPH_TABLE (property_graph_view
MATCH (u IS USER) -[i IS INTERACTS]-> (e IS ENTERPRISE)
-[t IS HAS_TIPOLOGY]-> (tp IS TIPOLOGY)
-[u IS HAS_UNIT]-> (un IS UNIT)
WHERE u.id = :user_id
COLUMNS (u.name, e.name AS enterprise, un.price)
)
**The dilemma:**While GRAPH_TABLE is extremely performant for structured traversals, I am considering extending our ontology with SEM_MATCH (RDF) to allow for logical inferences that go beyond the fixed property graph structure.For those of you operating GraphRAG in production on ADB: are you sticking strictly to the SQL Property Graph (GRAPH_TABLE) for the sake of unified transaction consistency, or are you hybridizing with RDF/SPARQL to handle the semantic "reasoning" layer?I’m worried that maintaining a dual-structure (PG + RDF) will introduce unnecessary overhead in terms of synchronization and data governance. However, the expressiveness of RDF for asset validation seems tempting.Would love to hear how you’ve balanced traversal speed vs. semantic flexibility in your GraphRAG implementations.