BTW, is there a good "graph layer" for SQLite? I understand that graph databases use specific data structures to optimize for graph queries instead of row-oriented but sometimes you need something in the middle: representing graphs and doing basic queries.
It's nearly a decade old at this point and probably not optimal even for the time, so there may be better approaches, but here's a few basic algorithms on SQLite. PageRank is at the bottom.
I'm interested in this too. My hunch is that SQLite would be a particularly good fit for a whole bunch of queries thanks to this characteristic: https://www.sqlite.org/np1queryprob.html - "Many Small Queries Are Efficient In SQLite"
An algorithm that traverses a graph by performing hundreds of individual SELECT queries to follow a path should work much better against SQLite than against most other relational databases, due to the lack of network overhead in making each of those queries.
I was building something like this a few years ago - NetworkXum [1].
But now we just use a pure Graph implementation with NetworkX interface - UKV [2].
Common graph databases are network-based for scaling purposes. You do have a database server then you talk to the server somehow for the queries. Sqlite is a single-file database. You do not have a server so you do not need an extra layer in database side.
Instead, Run the graph algorithms on a stringifed json stored as a text in sqlite. They will be running in some process in anyway.
looks like SQLite supports with recursive which allows some graph oriented queries: https://www.sqlite.org/lang_with.html the mandlebrot query looks interesting :D
echoing _frkl: yes, kuzu aims to fill exactly this space. an easy to use dbms that gives you the ability to model your records as a graph, do common querying and transformations, and extractions all in a high-level graph-specific query language. we are very new and have quite a lot to go but it still implements many cypher clauses, so many things can still be done.
