Validation used to be limited by memory. Now it is limited only by your shapes. RDF Studio validates SHACL shapes inside its own Rust storage engine, reading the indexes where your data already sits — nothing is copied out. It passes 98 of the 98 approved cases of the official W3C SHACL Core test suite, and it validates a 133.5-million-triple dataset against 43 shapes in about 52 minutes.
Most SHACL tooling works the same way: pull the data the shapes target into memory, build a graph object, then check the constraints against it.
That design has one property that matters more than all the others — the ceiling is set by memory, not by your shapes. A dozen simple shapes against a large dataset is not a small job, because the expensive part happens before any constraint is evaluated. It is the copy, and past a few million triples it stops fitting.
On a small dataset nobody notices. But the same path against a genuinely large dataset does not get slower in a manageable way; it stops being possible.
That is the ceiling every "validate your knowledge graph" feature quietly runs into.
The RDF Studio engine takes the other route. SHACL Core is implemented in Rust, inside the storage engine, and it evaluates constraints by reading the store's own indexes directly — the same indexes that answer your SPARQL queries.
There is no extraction step, because there is nothing to extract. A shape that targets one class touches the index entries for that class. A shape that targets nothing present costs nothing. You pay for what your shapes reach, not for the size of the database they live in.
Two consequences follow immediately:
The engine implements SHACL Core, and passes all 98 approved cases of the W3C SHACL Core test suite.
The full case-by-case result, and what the suite does and does not cover, are in the W3C SHACL Conformance Report.
Measured against our own engine, on a 10-core Apple M1 Max laptop with 64 GB of memory:
Further optimisation is on the roadmap. Validation currently runs on a single core, and the in-memory index it builds first is shared with the reasoner — parallelising both is planned work, not a limit of the approach.
The 43 shapes were generated from the LUBM ontology with Model ▸ Shapes ▸ GENERATE FROM OWL; the 11 are the ones the LUBM 1000 template ships.
That is an impressive result for the size of the job: every one of 133.5 million triples in reach of 43 shapes and 203 property checks, in about 52 minutes. The shapes were generated from the dataset's own ontology, one per class — and the dataset is deliberately not shaped to pass, which is exactly what makes it a useful test of the reporting path as well as the checking path.
The numbers above answer does this hold up at scale? They do not answer is the reasoning right?, so the engine is checked separately against published answer keys and real ontologies: the W3C OWL 2 RL test suite (all 60 soundness cases), the W3C SHACL Core test suite (98 of 98), the DCAT-AP unit tests published by the European Commission, the OWL 2 RL conformance set of the Semantic Publishing Benchmark, and closures over the Financial Industry Business Ontology (FIBO) and the Gene Ontology — real ontologies with deep hierarchies that synthetic data does not exercise. Those suites measure correctness; the timings on this page are the performance figures, and they come from LUBM-1000 because a number measured on a small dataset says nothing about a large one.
Validation lives at Model ▸ Shapes: VALIDATE ALL runs every shapes file and a card's ⋮ ▸ Validate Data runs one, and the report comes back with the findings — severity, focus node, property, message, value and the constraint that failed — sortable by any column and filterable by severity, with a 'Results truncated' chip when a run finds more than the 10,000 findings a report keeps. The exported report also names the shape that produced each finding.
When a run covered every graph in the store, the report says so with a chip.
RDF Studio is a desktop and cloud application for building, exploring and governing knowledge graphs. Validation, reasoning and storage are its own — no external server required.