As was written above the question about a graph oriented "language" within SQLite can maybe done with a translation from a value enabled extension table into proper SQL statements. This way the graph language would just act as a simplified syntax for more complicated sql statements. My vision here would be some kind of automated translation of the graph query syntax into normal SQLite3 statements ... even with many join enhancements. I have no fears that SQLite3 would be able to use them ... Without showing examples and advantages for any new query syntax nobody becomes convinced to do in SQLite3 project what other projects are already doing. You, OP, gave a description of what we could work on in this thread - if you want to keep it alive for the purpose of showing where advantages could be expected. Let's start with one use case and show the table structure and the queries in both syntaxes. My experience is that talking about and comparing may make the vision more clear. My idea for syntax transformation from a graph language into sql statements is to use Lua or LuaJIT and its lpeg module with the [statement_vtab](https://sqlite.org/forum/forumpost/28c03d56a16d3301?t=h) as value enabled table extension; the Lemon parser is not known to me .. that could become a final implementation once some advantages would ever become supported natively in C. First make it run and then make it faster and optimized. I see potentials for future to continue looking at graph query languages.