Most triple stores describe their performance in adjectives. This page gives you the numbers, every stage of them, measured on a single laptop against the standard LUBM benchmark at its 1,000-university scale.
The dataset: LUBM-1000 — 133,573,856 triples, 22.2 GB of N-Triples. The machine: one desktop, macOS on Apple silicon, 10 cores, 64 GB RAM. No cluster, no server, no per-query tuning.
Everything below is RDF Studio's own engine measured on its own. LUBM is synthetic and regularly shaped in ways real data is not — it tells you about scale and about reasoning completeness, not that your data will behave identically.
The memory figure matters more than the clock. The file is 22.2 GB and the resulting store is far larger than RAM would allow if any stage held it whole. The import streams from disk, decompresses inside the parse, and splits parsing across cores — so peak memory is a function of the buffer, not of the file. That is why this runs 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.
Reasoning at this size is a batch job, not an interactive one. Half an hour once, then every query benefits. That is the right trade for a knowledge graph and the wrong one for a cache.
The LUBM query set is 14 original queries plus 14 extended ones, run against the fully materialised store. One pattern runs through all of it: selectivity decides the time, not database size.
Ten of the fourteen answer in single-digit milliseconds — against 133 million triples with 76 million inferred facts layered on top.
The slow ones are slow for an unremarkable reason: they return enormous result sets. Query 6 materialises 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 34 seconds.
Validating the whole 133.5-million-triple dataset against shapes generated from its own ontology takes about 34 minutes, holding 13.4 GB at peak.
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 checkable at all — the older approach of extracting the targeted triples into memory first needs 13–27 GB before the first constraint is even evaluated, and never finished this dataset.
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.
Every figure above is reproducible from the application's own benchmark screen — Admin ▸ Benchmarks — rather than a private script.