Recording data changes in RDF systems is a crucial capability, needed to support auditing, incremental backups, database replication, and event-driven workflows. In large-scale and low-latency RDF applications, the high volume and frequency of updates can cause performance bottlenecks in the serialization and transmission of changes. To alleviate this, we propose Jelly-Patch - a high-performance, compressed binary serialization format for changes in RDF datasets. To evaluate its performance, we benchmark Jelly-Patch against existing RDF Patch formats, using two datasets representing diferent use cases (change data capture and IoT streams). Jelly-Patch is shown to achieve 3.5-8.9x better compression, and up to 2.5x and 4.6x higher throughput in serialization and parsing, respectively. These significant advancements in throughput and compression are expected to improve the performance of large-scale and low-latency RDF systems.
Large-scale RDF databases and low-latency streaming applications require the highest levels of performance from serialization formats, so as not to bottleneck the system with slow serialization. This includes OLTP databases working with very frequent or large transactions, which must record the changes eficiently to quickly close each transaction. In streaming applications, small incremental changes to RDF datasets are common, such as the sensor value update in the example above. In this case, reducing the serialization/deserialization time and the size of the representation will result in lower latency and decreased usage of computing resources.
To answer these needs, in this work we introduce Jelly-Patch, an eficient binary serialization format
for RDF Patch. It is based on Jelly-RDF, a high-performance RDF serialization format [
Jelly-Patch uses Protocol Bufers, a fast and widely used binary serialization framework [
The base compression scheme in Jelly-Patch is the same as in Jelly-RDF [
We implemented Jelly-Patch in Java, as part of the Jelly-JVM library,2 licensed under Apache 2.0. The core serialization code is generic and can be integrated with any RDF library for the Java Virtual Machine. We integrated it fully with Apache Jena, including high-level APIs on par with Jena’s internal serialization formats. We also implemented a low-level integration with RDF4J, which is limited due to RDF4J not supporting RDF Patch natively.
We evaluated Jelly-Patch in terms of its serialized representation size, serialization throughput, and deserialization throughput. The benchmarks were performed with two datasets, representing very diferent use cases: change data capture of an RDF database, and streaming IoT sensor data.
The change data capture dataset (bsbm-cdc) was created using the Berlin SPARQL Benchmark
(BSBM) [
The streaming IoT sensor dataset (assist-iot-weather) is based on a RiverBench [
Table 1 presents key statistics about both datasets. In this case, we consider a patch to correspond to
exactly one transaction. An operation is a single row in an RDF Patch file (e.g., transaction begin, triple
add/delete, header). The datasets are publicly available on Zenodo under the CC BY 4.0 license [
Benchmarks were implemented on top of Apache Jena 5.3.0, using Jelly-JVM 3.4.0. We used the following
Jelly-Patch settings: name table size 4000, prefix table size 1024, frame size 512. We compared it against
formats built into Jena: RDF Patch text (same as described in the RDF Patch specification), RDF Patch
binary (based on Jena’s binary Thrift format [
For serialization, an in-memory list of changes was sent to the serializer writing to a blackhole output stream, discarding the written bytes. For deserialization, the parser was reading from an in-memory byte array, containing pre-serialized data. The results were sent to a blackhole change handler.
The benchmark was implemented using the Java Microbenchmark Harness (JMH) 1.37, an
industrystandard benchmarking tool that accounts for JVM warmup and dead-code elimination using JVM
blackholes, ensuring fair results [
Figure 1 compares the serialized representation size of the four formats, with RDF Patch text being used as the baseline. RDF Patch binary does not employ any compression, and results in files ∼ 20% larger than with the text format. Jena’s SPARQL Update implementation also does not use any compression, with files 21–33% larger than the text format. Jelly-Patch is the only format employing any compression, reducing the file size by 3.5x for bsbm-cdc, and by 8.9x for assist-iot-weather.
The observed diference in compression ratios is due to bsbm-cdc using long literals and a very large pool of quickly changing IRIs (e.g., 100,000 products). Jelly-Patch does not apply binary compression to literals – to alleviate this, the file would have to be additionally compressed with, for example, gzip. Conversely, in assist-iot-weather the literals are small and IRIs repeat often, making them prone to Jelly’s compression mechanisms.
The compressed weather dataset when saved as a change stream in Jelly-Patch takes up only 279.6 MB, as compared to 1513.8 MB of the original RiverBench dataset saved in Jelly-RDF, while not losing 3https://w3id.org/riverbench/datasets/assist-iot-weather-graphs/1.0.3 4https://github.com/Jelly-RDF/jvm-benchmarks
bsbm-cdc t e s a t a D assist-iot-weather 11.2% 28.9% any information. This is a size reduction of 5.4x, made possible by applying diferential compression (stream derivative) on top of an already well-compressed file. This highlights the great potential of dif-based formats in streaming use cases, which we will investigate further in future research.
Figure 2 presents the serialization and deserialization throughput results. SPARQL Update does not have a RDF Patch-compatible parser, so only its serialization speed was tested, with it being by far the slowest format. In bsbm-cdc, Jelly-Patch is only ∼ 5% faster at serializing than Jena’s binary format. This is due to the dataset being a pessimistic case for Jelly-Patch, with a lot of incompressible data (long strings) and few repeating structures. Nonetheless, Jelly-Patch delivers over 4x better compression at nearly the same serialization throughput, making it much more advantageous. In assist-iot-weather, Jelly-Patch has 2.5x faster serialization than Jena’s binary format.
In this work, we introduce Jelly-Patch, a fast binary format for recording changes in RDF datasets. In the conducted experiments, it achieved 3.5–8.9x better compression than other RDF Patch formats, while being up to 2.5x faster to serialize, and up to 4.6x faster to parse. This is a significant diference that is expected to greatly benefit large-scale RDF systems, especially in networked or distributed settings. The format is not only useful in CDC scenarios, but also for representing streams of sensor data, achieving 5.4x better compression than the already well-compressed Jelly-RDF.
We plan to continue optimizing both Jelly-RDF and Jelly-Patch through new compression schemes
and improvements in implementation eficiency. Also planned are: implementations for Python and
Rust, conformance test cases, and extending the jelly-cli with commands for Jelly-Patch. Extensive
benchmarks should be performed, using more datasets, which can be contributed to RiverBench [
This work was financially supported from the European Funds under the Sector Agnostic path of the Huge Thing Startup Booster program (project no. 0021/2025, program FENG.02.28-IP.02-0006/23).
Declaration on Generative AI. During the preparation of this work, the authors used ChatGPT in order to draft content. After using this tool, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content.
Jelly-Patch specification: https://w3id.org/jelly/dev/specification/patch
Jelly-JVM documentation: https://w3id.org/jelly/jelly-jvm
Datasets and full results: https://doi.org/10.5281/zenodo.16498682 [