A single laptop, 133,573,856 triples, and every stage measured. Loading, full OWL 2 RL reasoning, SHACL validation and the complete LUBM query set — run end to end on one desktop machine, with the numbers written down as they came out.
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 gzipped N-Triples.
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 our own engine on one machine — macOS on Apple silicon, 10 cores, 64 GB RAM. 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.
Importing the full dataset through the application takes 3 minutes 14 seconds, sustaining about 117 MB/s, and never uses more than 4.4 GB of memory.
The memory figure is the one worth pausing on. The file is 22.2 GB and the store ends up far larger than RAM would allow if any stage held it all — 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.
This is the part that usually decides whether a triple store is usable for knowledge-graph work, because the queries people want to write assume the inferences exist.
Computing the full OWL 2 RL closure over the loaded dataset takes 34.6 minutes and derives 76,357,937 new facts — more than half as many again as were loaded. Those facts are written back into the store, so every query afterwards reads them directly rather than re-deriving them. Nothing is recomputed per request.
Two custom inference rules on top of the standard profile, of the kind a modeller adds for their own domain:
The whole 133.5-million-triple dataset validates against shapes generated from its own ontology in 2,051 seconds — about 34 minutes — holding 13.4 GB at peak and returning 118,856,199 violations. (LUBM's generated data is deliberately not shaped to pass; the violation count is a test of the reporting path as much as the checking path.)
Validation runs inside the storage engine, reading the indexes where the data already sits. Nothing is copied out, which is what makes a dataset this size checkable at all. The same engine passes 98 of the 98 approved cases of the W3C SHACL Core test suite.
The LUBM query set is 14 original queries plus 14 extended ones, run against the fully materialised store. The pattern is consistent and worth stating plainly: selectivity decides the time, not database size.
Ten of the fourteen original queries return in single-digit milliseconds — Query 1 in 6 ms, Query 10 in 4 ms, Query 11 in 6 ms, Query 13 in 50 ms — against 133 million triples with 76 million inferred facts layered on top.
The slow ones are slow for an obvious reason. They return enormous result sets:
Query 6 is not doing hard work per row; it is materialising ten and a half million rows. Query 2 is the exception that proves the rule — only 2,528 rows, but a triangular join that has to be evaluated across the whole graph.
The extended set behaves the same way: most answer in milliseconds to a few seconds, with the heaviest — a deep path query returning 298,603 rows — at 34 seconds.
Everything above is one machine, one run, and reproducible from the application's own benchmark screen rather than a private script — which is the only reason we are willing to publish the numbers.
RDF Studio is a desktop and cloud application for building, exploring and governing knowledge graphs. Storage, reasoning and validation are its own.