A single laptop, 133,573,856 triples, and every stage measured. Loading, full OWL 2 RL reasoning, the complete LUBM query set and SHACL validation — run end to end on one desktop machine.
LUBM is the standard synthetic benchmark for RDF stores: a generated university dataset with a known ontology, known reasoning consequences, and a fixed set of queries whose correct answer counts are published. LUBM-1000 is the 1,000-university scale — 133,573,856 triples, 22.2 GB of N-Triples. We also run the 14 extended queries and two inference rules of LUBM Extended.
We run it because it is the only honest way to answer the question people actually ask: does this fall over on real data? Everything below is RDF Studio's own engine measured on its own, on one machine — a MacBook Pro with a 10-core Apple M1 Max and 64 GB of memory. No cluster, no server, no tuning per query.
A word on what this is not: LUBM is synthetic and its shape is regular in ways real data is not. It tells you about scale and about the reasoner's completeness. It does not tell you your own data will behave identically.
Loading, reasoning and the validation against the 11 shipped shapes were measured on 14–15 October 2026; the validation against the 43 generated shapes and the query timings come from runs on 14 September 2026, on the same machine.
Every stage in detail follows.
The import streams from disk, decompresses inside the parse, and splits parsing across cores, so the file is never held in memory whole. That is why a dataset this size loads on a laptop at all.
This is the stage that usually decides whether a store is usable for knowledge-graph work, because the queries people want to write assume the inferences already exist.
The closure derives more than half as many facts again as were loaded, and writes every one of them into the store. Queries afterwards read them directly — nothing is re-derived per request.
The two rules come from LUBM Extended — the original LUBM defines none. Both, with the queries they serve, are on the LUBM Queries page.
You pay for reasoning once, not on every query. It runs as a background job — about 30 minutes for this dataset — and from then on every query reads the derived facts straight from the store, so a reasoned database answers as fast as a plain one. When the data changes, you run it again.
LUBM defines 14 queries; we run those plus the 14 extended queries of LUBM Extended, against the fully materialised store — each query run once to warm up and twice timed, the average shown. Every answer count matches the published LUBM figures. One pattern runs through all of it: the work a query has to do decides the time, not database size.
Ten of the fourteen answer in milliseconds — against 133 million triples with 76.4 million inferred facts layered on top.
The slow ones are slow for an unremarkable reason: they return enormous result sets. Query 6 returns ten and a half million rows; Query 14 returns nearly eight million. Query 2 is the interesting exception — only 2,528 rows, but a triangular join evaluated across the whole graph.
The extended set asks harder structural questions — deeper paths, more joins — so more of them land in the seconds rather than the milliseconds. The heaviest, a deep path query returning 298,603 rows, finishes in 32.5 seconds.
Validating the whole 133.5-million-triple dataset against 43 shapes generated from its own ontology — 203 property checks — takes about 52 minutes and reports 126,524,282 violations, an impressive result for a job that size. The 11 shapes the LUBM 1000 template ships — 34 property checks — take about 43 minutes and report none.
Validation runs inside the storage engine, reading the indexes where your data already sits. Nothing is copied out, which is what makes a dataset this size practical to check.
The same engine passes 98 of the 98 approved cases of the W3C SHACL Core test suite. The full case-by-case result is in the W3C SHACL Conformance Report.
The next benchmark on our roadmap is LUBM-8000 — eight times this size: 1.1 billion triples loaded, almost 2 billion after reasoning. We will publish it the same way: every stage, one machine.
Every figure above is reproducible from the application's own benchmark screen — Admin ▸ Benchmarks — rather than a private script.
RDF Studio is a desktop and cloud application for building, exploring and governing knowledge graphs. Storage, reasoning and validation are its own.