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 in about 34 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. Extracting 133.5 million triples into an in-process Python graph needs somewhere between 13 and 27 GB of memory before the first constraint is checked, and in our measurements it simply never completed.
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 advanced features — sh:sparql, sh:js, sh:rule — are refused by name rather than silently skipped, because a report that says "conforms" because a constraint was ignored is a wrong answer delivered with confidence.
sh:sparql
sh:js
sh:rule
The full case-by-case result, and what the suite does and does not cover, are in the guide Learn ▸ Guides ▸ The W3C SHACL Test Suite.
Measured on one machine, against our own engine:
The LUBM-1000 run used the shape set generated from that dataset's own ontology, held 13.4 GB at peak, and returned 118,856,199 violations — 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.
For comparison with the old approach on the same dataset: the extract-then-validate path never finished it at all.
Validation lives at Model ▸ Shapes ▸ VALIDATE DATA. Pick a shape file or run them all, and the report comes back with every finding — focus node, path, value, severity, message, the shape that produced it and the constraint component that failed — sortable and filterable, with a truncation indicator when results exceed the limit you set.
When validation ran inside the storage engine, the report says so with a chip, so a fast result on a very large database reads as explained rather than suspicious.
Validation also runs on individual records as you edit them, using the same engine and the same shapes, so the constraint that governs your data at rest is the constraint that governs it at write time.
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.