SPARQL Engines and Triplestores: Fuseki, Virtuoso, QLever and How to Choose
An ontology is a theory until an engine has to answer a question about it in under a second. Everything so far in this module has been about what you can say. This lesson is about what happens when you say it at scale, because the triplestore you pick decides how big your graph can get, how fast it loads, whether you can update it in place, and whether reasoning is something you run or something you gave up on.
The families, and what each is for
Apache Jena Fuseki is the reference-quality open option: Apache 2.0, TDB2 for storage, a mature Java ecosystem, and jena-text for Lucene-backed full text search. It is the right default for development, for teaching and for most graphs up to the low hundreds of millions of triples. It is not the one you reach for at billions.
Virtuoso from OpenLink is the veteran, with an open-source edition and a commercial one, a SQL engine underneath, and a long track record hosting large public endpoints. It rewards operators who are willing to learn its tuning knobs and punishes those who are not.
Oxigraph is the Rust option: small, embeddable, permissively licensed, and pleasant to ship inside an application. Think of it as SQLite for RDF rather than as a data centre engine.
QLever, from the University of Freiburg, is the one that has changed the conversation at the top end. It holds the full Wikidata graph, in the order of seven billion triples, in roughly 40 GB of RAM, builds its index in under twelve hours, and answers most queries in under a second. It reached full SPARQL 1.1 compliance in June 2025, including SPARQL Update and the Graph Store HTTP Protocol, work carried out under the European Next Generation Internet Search programme. Independent benchmarking on real Wikidata query logs during 2025 and 2026 found it the fastest of the open-source engines tested, and far faster than Blazegraph.
On the commercial side, GraphDB, Stardog, AllegroGraph and RDFox sell what open engines mostly lack: supported reasoning, security models, clustering and somebody to ring. RDFox is the outlier worth knowing, because it is a Datalog materialisation engine with RDF interfaces rather than a triplestore that added rules. Amazon Neptune is the managed option if your constraint is operational headcount rather than licence cost.
Worked example · the Aberdeen-2 asset register
Where we left it: reasoning costs assigned; the register needs a physical home.
Fuseki, the lesson’s right default at this scale. Each source loads into its own named graph over the Graph Store HTTP Protocol, preserving lesson 5’s partitioning:
curl -X PUT --data-binary @engineering.ttl \
-H 'Content-Type: text/turtle' \
'http://localhost:3030/register/data?graph=https://data.example.com/id/g-engineering'
# then the query the whole course has been walking towards:
SELECT ?g (COUNT(DISTINCT ?p) AS ?pumps)
WHERE { GRAPH ?g { ?p a ex:Pump } }
GROUP BY ?g?g ?pumps
ex:g-engineering 44
ex:g-maintenance 41
ex:g-contractor 39Lesson 1’s three irreconcilable answers, in one result set, each attributed to the conceptualisation that produced it. The numbers no longer fight; they inform the entity-resolution work to come, because the deltas point exactly at the standby trains, the warehouse spares and the abandoned position. If the register ever grows fleet-wide and read-mostly at billions of triples, the lesson’s ladder says QLever; today, Fuseki on a laptop answers in milliseconds. Pay for the problem you actually have.
State of the register: hosted, partitioned, queryable over HTTP. Next: the property-graph world, and what survives the crossing.
The case study to quote in meetings
The most visible SPARQL endpoint in the world is changing its engine. The Wikidata Query Service runs on Blazegraph, which has been effectively unmaintained since its team was acquired, and the Wikimedia Foundation has been explicit that Blazegraph’s limitations cause much of the service’s instability and cannot scale to Wikidata’s growth. QLever has been proposed as the replacement, with a phased migration beginning in the financial year starting July 2026, community test endpoints first and rollout after that.
Two lessons come out of that, and both transfer. First, an unmaintained engine is a liability no amount of SPARQL compliance offsets: check commit history and release cadence before you check benchmarks. Second, migrating a query engine is not a database swap, it is a query rewriting project, which is why Wikimedia funded documentation and query rewriting support alongside the migration. Budget for that.
| Question to ask | Why it decides |
|---|---|
| How many triples, and how fast do they load? | Load time governs your rebuild cycle. An engine that takes three days to index cannot be rebuilt nightly |
| Bulk reload or live updates? | Read-mostly graphs rebuilt from source suit index-optimised engines. Live editing needs solid SPARQL Update support |
| Do you need reasoning, and which kind? | Materialisation at load, as RDFox and GraphDB offer, versus query rewriting, versus none. This is the single biggest differentiator |
| Full text and vector search? | Support ranges from Lucene integration to nothing. Often better solved by a dedicated index keyed on the IRI |
| Licence and deployment | Free tiers move between versions. Read the terms for the version you will actually run |
| Is it maintained? | Commit history, release cadence and a real issue tracker. See Blazegraph |
What breaks · loading everything into the default graph
The quick version of the load skips the graph parameter three times:
tdb2.tdbloader engineering.ttl maintenance.ttl contractor.ttl
# one undifferentiated pile of triplesSet union is irreversible without the fourth element. “Which source said P-101 is rated 18.5 kW?” is now unanswerable: the engineering decimal and the contractor string both hang off ex:P101 with nothing to distinguish their pedigree, so the deduplication that needed to prefer the engineering value has lost its evidence. The per-source count query above degenerates to a single number that is the union of three conceptualisations, which is to say, lesson 1’s disease with extra steps. And when the contractor reload goes wrong, as it did with the string-valued powers, the recovery is surgical DELETE statements against a live store instead of DROP GRAPH followed by a clean reload. The named-graph strategy costs one URL parameter per load; retrofitting it later, as lesson 5 warned, is a migration.
Reading benchmarks without being fooled
Published triplestore benchmarks are close to useless when the query mix does not resemble yours. Synthetic suites reward engines tuned for them, and vendor benchmarks reward the vendor. The Wikidata benchmarking work is a good model precisely because it runs real query logs against several engines on the same hardware and publishes the queries. Copy the method rather than the conclusion: take a hundred of your own queries, run them on two candidates on identical hardware, and measure the tail latency rather than the mean, because the ninety-fifth percentile is what your users experience.
A sane default path: Fuseki or Oxigraph while you are modelling, QLever when the graph gets genuinely large and is read-mostly, and a commercial engine only when you need supported reasoning, fine-grained security or a support contract. Pay for the problem you actually have.
Next we cross to the other side of the graph world entirely, to property graphs, Cypher and ISO GQL, and to the question of what survives the journey between the two.
Check yourself
The register goes fleet-wide: 40 platforms, around two billion triples, read-mostly analytics, a nightly batch refresh, a two-person team and no budget for a support contract. Which engine fits?
- QLever
- Apache Jena Fuseki
- Oxigraph
- Blazegraph, since the world’s most visible endpoint runs on it
Show the answer, and why each wrong option is wrong
A is correct. Billions of triples, read-mostly, batch-refreshed is QLever’s exact shape: Wikidata-scale data in tens of gigabytes of RAM, sub-second queries, and an index build measured in hours, which a nightly batch window accommodates. Full SPARQL 1.1 compliance since June 2025 removes the old caveat.
B is the right default everywhere earlier in the register’s life, and this lesson is explicit about its ceiling: low hundreds of millions of triples, not two billion. Defaults have scopes. C is aimed at a different tier entirely, SQLite-for-RDF, embeddable inside an application; it is not a data-centre engine. D inverts the case study: Blazegraph is effectively unmaintained, its limitations are the stated cause of the endpoint’s instability, and Wikimedia is migrating off it. An unmaintained engine is a liability no benchmark offsets, and commit history is the first thing to check, before performance.
