OxiRS v0.2.4 Brings Full-Stack Semantic Web Capabilities to Rust

The semantic web stack has long been Apache Jena's territory: sprawling Java dependencies, a JVM to feed, and a binary footprint that makes embedding in constrained environments a genuine headache. OxiRS v0.2.4, pushed to the `cool-japan/oxirs` repository on March 28, cuts through that orthodoxy with a pure Rust alternative that claims feature parity in a sub-50MB static binary.

The release touches every layer of the workspace. The core crate benchmarks show point queries against a warm cache resolving in 0.8 microseconds, complex SPARQL completing in 0.5 milliseconds, and memory consumption at 100 million triples sitting at 2.1 GB against a naive implementation's 24 GB; that is a 91 percent reduction. The SPARQL engine covers the full W3C 1.1 surface plus the 1.2 extensions: RDF-star, enhanced property paths, and advanced aggregations all ship as first-class features, not bolted-on plugins. The query optimizer, described in the changelog as delivering 3.8x faster execution through automatic complexity detection, is baked into the engine crate rather than requiring separate configuration.

Five concrete capabilities define what v0.2.4 makes viable for a self-hosted knowledge graph. The SPARQL endpoint, served via `oxirs-fuseki`, is wire-compatible with Apache Fuseki's HTTP protocol, meaning existing client tooling drops in without modification. Persistent storage defaults to N-Quads, with seven import/export formats supported: Turtle, N-Triples, RDF/XML, JSON-LD, N-Quads, TriG, and N3. SHACL validation reached production release at v0.2.2 in mid-March, and GeoSPARQL 1.0/1.1 support arrived at v0.1.0 in January, both as standalone crates that compose cleanly via Cargo features. The CLI, installed with `cargo install oxirs`, exposes `init`, `import`, `query`, `serve`, and `benchmark` commands with stable public APIs.

Getting a working triple store running from scratch takes four commands. Initialize a named graph with `oxirs init mykg`, load a Turtle file with `oxirs import mykg data.ttl format turtle`, then fire a query: `oxirs query mykg "SELECT ?name WHERE { ?person <xmlns.com/foaf/0.1/name> ?name }"`. The data persists automatically to `mykg/data.nq` between sessions, so cold restarts reload from disk without re-importing. Promote that graph to a live SPARQL endpoint with `oxirs serve mykg/oxirs.toml port 3030` and it accepts standard SPARQL Protocol HTTP requests immediately.

Where does OxiRS fit against the other Rust options? Oxigraph, the established library in this space and the project OxiRS explicitly builds on top of, is the safer conservative bet: battle-tested RocksDB storage, clean embedding API, and a mature community. If you need a library that slots into an existing Rust service with minimal surface area, Oxigraph is still the first choice. OxiRS is the right call when you want the whole platform: a CLI, a Fuseki-compatible server, SHACL validation, GeoSPARQL, RDF-star, Python and Node bindings in a single coherent workspace, and a roadmap that includes GPU-accelerated query work. The tradeoff is a younger project with more moving parts to track.

The broader signal in v0.2.4 is about trajectory. OxiRS shipped its initial production release on January 7, passed 13,123 tests with zero warnings at that point, and has pushed multiple production-tagged releases across the workspace in under three months. For teams building knowledge graphs, IoT telemetry pipelines, or enterprise data meshes who want to stay entirely inside the Rust toolchain, the inflection points to watch are the Python and Node bindings reaching stable releases and the appearance of Docker packaging artifacts: those two milestones will determine whether OxiRS becomes a serious challenger to the JVM stack in production deployments.