We're not too far along that it would be possible to swap out the wonderful sqlite for an RDF triple store, i've scouted around a bit and think oxigraph would be the best fit here if we choose to take this route.
Pros:
The fediverse is in JSON-LD, which is a form of RDF, so we would be able to natively handle activitypub a lot easier and more coherently than trying to fake it with SQL the way masto and a lot of other projects do
Graph DBs are easier to have mutating database schema: much less of a need for a bunch of migrations, i don't rly know if we need them at all except for renaming properties and whatnot
Graph DBs handle heterogeneous data better, so that would lend itself well to a lurching, mutating, crawling machine.
A lot of scholarly metadata is in RDF, and so we would be able to represent that natively at a database level
I actually don't know if any AP software uses a graph DB because the usual ones are super unwieldy, oxigraph is relatively new as a lightweight graph/RDF database. Pleroma uses JSON in postgres, i think that's the closest i know of? so this might be a novelty as far as AP tooling goes
Much more interesting interoperability potential
Much richer query space - SQL queries are obviously very expressive, but the database layout impacts the kinds of queries that are fast and not cumbersome to do, and the graph DB would allow us to be much more nimble in how we can parameterize queries and how we recombine data.
(personal) it aligns better with my longterm goals
Cons:
We're already using sqlite
Way, way, way less support and documentation vs. SQLAlchemy and SQLModel.
Way, way, way less tested than the absolutely absurdly tested sqlite
Worse developer experience in the short term - we would have to do a bit of legwork to get something approximating ORM levels of familiarity to python ppl
Less familiar to a broad cross section of potential collaborators
Potentially more resource intensive (don't know)
Potentially less performant (don't know)
Basically I want to try it before we get too far. we haven't done a lot of virtualization of the DB really, the models sort of do that but we would have to do a decent amount to actually make that real if we, eg. wanted to have two backends (that sounds like a real pain, let's not do that)
I think i'm going to try it out in a branch and see how hard it is to replicate functionality, but posting this here in case anyone else is interested in trying this out with me, it could be fun :)
We're not too far along that it would be possible to swap out the wonderful sqlite for an RDF triple store, i've scouted around a bit and think oxigraph would be the best fit here if we choose to take this route.
Pros:
Cons:
Basically I want to try it before we get too far. we haven't done a lot of virtualization of the DB really, the models sort of do that but we would have to do a decent amount to actually make that real if we, eg. wanted to have two backends (that sounds like a real pain, let's not do that)
I think i'm going to try it out in a branch and see how hard it is to replicate functionality, but posting this here in case anyone else is interested in trying this out with me, it could be fun :)