[wslh]

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.

[robmccoll]

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.

https://github.com/robmccoll/graphdb-testing/blob/master/tes...

The graph is just an indexed edge list with auxiliary tables to support algorithms as needed.

[AmateurLeader]

Sounds like EdgeDB [0] might be of interest to you

[0] https://www.edgedb.com

[alberth]

> "That said, EdgeDB is built on top of Postgres."

[katrotz]

That made my day, thanks for sharing it

[vlmutolo]

Cozo (cozodb.org) is a new embedded graph database that has many available storage backends, including SQLite.

It’s not a thin layer, though, if that’s what you’re looking for. Cozo has its own query system and uses a datalog-like query language.

[simonw]

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.

[NicoJuicy]

This should make it a lot better: https://github.com/abetlen/sqlite3-bfsvtab-ext

[ashvardanian]

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].

[1]: https://github.com/unum-cloud/networkxum [2]: https://github.com/unum-cloud/ukv

[fatih-erikli]

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.

[marksbrown]

SimpleGraph might be worth a look. I've found it useful. https://github.com/dpapathanasiou/simple-graph

[conceptme]

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

I haven't used it on SQLite but I have done basic graph queries in postgres with `with recursive` some examples can be found here: https://www.alibabacloud.com/blog/postgresql-graph-search-pr...

[_frkl]

Not sqlite, but kuzu ( https://github.com/kuzudb/kuzu ) is an interesting project in this space. Fairly new, but already quite impressive IMHO.

[mbuda]

Don't know about SQLite, https://github.com/apache/age seems very interesting, but it's just a tiny layer on top of Postgres :)

[semihsalihoglu]

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.