Interesting. SQLite is awesome.<p>I did something similar recently, a block store for a rust implementation of ipfs, which models a directed acyclic graph of content-addressed nodes.<p><a href="https://github.com/actyx/ipfs-sqlite-block-store" rel="nofollow">https://github.com/actyx/ipfs-sqlite-block-store</a><p>I found that performance is pretty decent if you do almost everything inside SQLite using WITH RECURSIVE.<p>The documentation has some really great examples for WITH RECURSIVE. <a href="https://sqlite.org/lang_with.html" rel="nofollow">https://sqlite.org/lang_with.html</a>
Tangentially related to graph dbs, but if you're looking for more hierarchical support, SQLite does has a transitive closure extension[0] that might be of some assistance. I leveraged this back in 2014 to write our framework-agnostic result storage on AWS Device Farm.<p>[0] - <a href="https://www.sqlite.org/cgi/src/artifact/636024302cde41b2bf0c542f81c40c624cfb7012" rel="nofollow">https://www.sqlite.org/cgi/src/artifact/636024302cde41b2bf0c...</a><p>[1] - <a href="https://charlesleifer.com/blog/querying-tree-structures-in-sqlite-using-python-and-the-transitive-closure-extension/" rel="nofollow">https://charlesleifer.com/blog/querying-tree-structures-in-s...</a>
Why not add that functionality directly to SQLite via stored procs*<p><a href="https://www.amazon.com/Hierarchies-Smarties-Kaufmann-Management-Systems/dp/0123877334" rel="nofollow">https://www.amazon.com/Hierarchies-Smarties-Kaufmann-Managem...</a><p>*<a href="https://github.com/wolfch/sqlite-3.7.3.p1" rel="nofollow">https://github.com/wolfch/sqlite-3.7.3.p1</a>
I really like this, OP. I'm member of the clan "why are you creating your own XDR, just use sqlite!!" and have oft jumped to that in technical discussions, so appreciate it.<p>However, what's lacking from something like this is a detailed bill of the cost. I'd love to see some, <i>any</i> benchmark on a DB with > 10^6 edges to see how it goes. That's the other hand of the equation "just use sqlite and be happy" -- the expectation that performance will actually be reasonable.
Similar project: <a href="https://github.com/CodyKochmann/graphdb" rel="nofollow">https://github.com/CodyKochmann/graphdb</a>
I wonder if there are ways, in SQLite, to build indices for s,p,o/s,p/p,o/ and maybe more subtle ones...
That would be uber nice, given the fact that most graph databases have their own indexing strategies, and you cannot craft your own.
Isn't the whole point of graph databases that they can traverse graph edges efficiently by following pointers to nodes, which relational databases can't do? Then it seems a bit strange to implement a graph database on top of a relational database like SQLite?