Thank you @So9q for opening this task!

Some comments:

• Oxigraph is dual licensed under Apache2 or MIT, not under GPLv2.
• Oxigraph plans to drop the RocksDB backend in the next release and focus on Sled. It will make the development easier.

Some other possible pros and cons:

Pro:

• standalone (no need to deploy a set of services)

Cons:

• unstable (no guaranteed storage format stability for now)
• no query optimizer (not implement yet)
• single server system just like Blazegraph (no distribution)

Hi @Tpt Can you elaborate more in your Milestones and create more Milestone as necessary for your future vision? Like what you mean by "no storage format stability for now", and what that really means to users and what you are thinking about in the long term towards solving that?
Maybe a ROADMAP.md file in the repo might be good to add as a quick high-level overview, which then has links to Milestones (and perhaps make more future vision Milestone links, even if 2 years away, or just a dream but wrapped with practicality).
https://github.com/oxigraph/oxigraph/milestones

GitHub Milestones are a great place to capture your future vision (even if some of it never happens!) You did great on the .3 Milestone description, but you are describing Sled backend without giving the actual problem description or context that your thinking of solving with Sled? As you just did within here on Phabricator.)
Could I ask you to perhaps frame up the general problems in the Milestones, what solutions your thinking of to solve them, and then add that detail using bullet points in the actual Milestone descriptions to give folks an idea of some of the ideas or features your thinking about.

Thanks again for all that you do!

@Thadguidry Hi! It's a great idea to improve the roadmap. Thank you for pushing me to do that! I have updated the GitHub issues and milestones and added a link to them in the README:
Each milestone should now have a short description and a set of linked issues. Most of the issues have been connected to a milestones.
I am a bit afraid of adding a ROADMAP file to the repository because it is yet another source of truth to maintain.
To also keep a single source of truth I made the choice to not expand the milestone description too much and keep the detailed discussions inside of issues. Here is [one about the storage backend and Sled]( https://github.com/oxigraph/oxigraph
/milestones?direction=desc&sort=completeness&state=open). However, the milestone+connected issues descriptions should allow to make sense of the roadmap. Feel free to ping me if you believe it's not clear enough.

@Tpt Looks great! The ROADMAP file was a suggested alternative to the Milestones, sorry didn't make that clear. I much prefer grouping or tagging issues against Milestones as you have done! You have the right idea regarding a single source of truth and exactly the best practices! Your a natural.

@Tpt thanks for the corrections!

@Tpt is it possible to run a cluster of say 2 oxigraph instances on the same sled store?
I could then manually update the sled store in some way and the changes are visible in both of the oxigraph endpoints?

@Thadguidry Great! Thank you!

@So9q Sadly it's not possible with Sled. But Sled and Oxigraph should both work fairly well with multiple parallel thread so updating data while serving query should work ok. I have started to run some benchmarks around it. I still need to polish them a bit before publishing them.

@Tpt - is there a plan to decouple the Sled store and the query handlers in Oxigraph to allow the use case that @Thadguidry was asking about? Under high, concurrent write situations (i.e. if writers to Oxigraph weren't limited to a constrained number that kept a suitable amount of READ threads available), I could see the desire for decoupling and Oxigraph seems to be the most natively close to decoupled from what I've seen :)

@BenAtOlive If I understand correctly, you are asking if Oxigraph can be used to build a distributed SPARQL database with reader nodes and writer nodes? Its definitely possible to reuse Oxigraph components for that. For example I am currently moving the SPARQL parser out of Oxigraph and I plan to add general SPARQL query optimizations to it. However, building a query evaluator against a distributed storage where data are not in the same machine as the one executing (or at least scheduling) the query is a quite different task as building a query executor against a single node database. Access latencies are easily an order of magnitude higher with a remote store and it changes quite a lot of tradeoffs. So, yes for making the part of Oxigraph that are easy to reuse reusable but sadly I am not sure that naively spliting the query evaluator out of Oxigraph would provide a good query evaluator on top of a distributed storage.

@Tpt - thank you for the detailed response. I've been wondering about this lately, and the tradeoffs you outlined are definitely a strong reason to not do it. Distributed SQL/NoSQL databases have proven to be quite powerful and it is inevitable to think can we build a distributed SPARQL database, but graph data is stored, retrieved, and optimized differently than the more popular/common paradigms. If nothing else, I am eager to try Oxigraph in various topologies given the optimizations that you are currently working on!

As someone who has "been there, done that" (even with Apache Geode)... I can tell you that data locality is very important when you want to maximize performance. But if the data is maintained as distributed, then the only way to squeeze out improved performance is if you can temporarily have that data locality and that sometimes means temporary or ad hoc data replication...which has a cost itself but isn't insurmountable.

@Thadguidry - that's a very good point. We've done the non-temporary N replica model with Fuseki before and have the pods fronted by an ALB, but this doesn't really distribute anything--it just gives some horizontal scalability. I don't want to take over this ticket with what I hope to be a good conversation, is there a better place on here to chat w/ you and @Tpt?

@Thadguidry @BenAtOlive It's a great idea to move the conversation somewhere else. Oxigraph has a discussion space and a Gitter channel.

@BenAtOlive I think for bikeshedding or hand-waving discussions, you can just start an new discussion thread in Oxigraph's GitHub Discussions (not Issues). Here: https://github.com/oxigraph/oxigraph/discussions

I'm closing this task since Oxigraph is not on the shortlist of Blazegraph alternatives, as per https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update/WDQS_backend_alternatives

What is the reason Oxigraph was shortlisted? Is this documented somewhere?

@DD063520 , thanks for asking. Please refer to the attached paper for more details on the criteria we used to decide on our shortlist, which includes a note on Oxigraph: https://upload.wikimedia.org/wikipedia/commons/e/ea/WDQS_Backend_Alternatives_working_paper.pdf

Hi, I saw the document, but I'm a bit confused. Because the criteria are basically checked for the shortlisted solutions. But in which part do you explain why for example Oxigraph was not shortlisted. I did not read the full document from start maybe i miss something, it's just to understand ....

In T289760#7874365, @DD063520 wrote:

Hi, I saw the document, but I'm a bit confused. Because the criteria are basically checked for the shortlisted solutions. But in which part do you explain why for example Oxigraph was not shortlisted. I did not read the full document from start maybe i miss something, it's just to understand ....

It was on page 35. They basically said it was too early in its development.