QLever - https://github.com/ad-freiburg/qlever - https://scholia.toolforge.org/work/Q108730896

The paper reports benchmarks favorable for QLever. I cannot get path queries working on the public endpoint.

(QLever could be a candidate. It is not a criteria)

Hernández, Daniel & Hogan, A. & Krötzsch, M.. (2015). Reifying RDF: What works well with wikidata?. 1457. 32-47.

Abstract: In this paper, we compare various options for reifying RDF triples. We are motivated by the goal of representing Wikidata as RDF, which would allow legacy Semantic Web languages, techniques and tools - for example, SPARQL engines - to be used for Wikidata. However, Wikidata annotates statements with qualifiers and references, which require some notion of reification to model in RDF. We thus investigate four such options: (1) standard reification, (2) n-ary relations, (3) singleton properties, and (4) named graphs. Taking a recent dump of Wikidata, we generate the four RDF datasets pertaining to each model and discuss high-level aspects relating to data sizes, etc. To empirically compare the effect of the different models on query times, we collect a set of benchmark queries with four model-specific versions of each query. We present the results of running these queries against five popular SPARQL implementations: 4 store, BlazeGraph, GraphDB, Jena TDB and Virtuoso.

Consider graph databases that support RDF-star and SPARQL-star such as RDF4J, AnzoGraph and GraphDB since they are proposed extensions to the RDF and SPARQL standards to provide a more convenient way to annotate RDF statements and to query such annotations (wikidata qualifiers and references), bridging the gap between the RDF world and the Property Graph world.

See W3C Draft Community Group Report 01 July 2021
https://www.w3.org/community/rdf-dev/2021/07/02/new-public-draft-of-the-rdf-star-report/

https://rdf4j.org/documentation/programming/rdfstar/
https://graphdb.ontotext.com/enterprise/devhub/rdf-sparql-star.html
https://cambridgesemantics.com/anzo-platform/

Re the prior candidate list:

Prior candidate list and survey from when Blazegraph was chosen: https://docs.google.com/spreadsheets/d/1MXikljoSUVP77w7JKf9EXN40OB-ZkMqT8Y5b2NYVKbU/edit?usp=sharing

It would be great to have annotated scale to help figure what software looks like the best candidate, and avoid gut jugdment.

Given a "multi operation ACID", it might look like:

• 0: No ACID guarantees
• 1: ACID guarantees for primary representation, but async secondary representations (indices)
• 2: ACID both primary and secondary representations

Regarding ACID in particular, there is another lever that is "isolation level", see https://www.postgresql.org/docs/current/transaction-iso.html.

Also the current scale 0-10 is way to large, it is too much work to document for every row what every number means between zero and ten.

It seems clear that that sheet is just an indicator, and only gives clues of what might work best, and grading well on that can not be the primary motivation for picking a solution.

Design for ~10X growth, but plan to rewrite before ~100X

Jeff Dean, “Challenges in Building Large-Scale Information Retrieval Systems,” Google, http://static.googleusercontent.com/media/research.google.com/en//people/jeff/WSDM09-keynote.pdf