If you're running Zenoh, whether as rmw_zenoh in ROS 2 or as the transport between a robot, a gateway, and the cloud, you'll eventually run into the same question:

"Where does this data actually go? I need to replay yesterday's run, debug a fault from a remote robot, and pull a few thousand frames for training."

There's plenty of material on the communication layer itself: pub/sub primitives, how Zenoh compares to DDS, multi-node setups down to a Raspberry Pi. rmw_zenoh reached Tier-1 status starting with ROS 2 Kilted Kaiju, and it's getting real attention at events like ROSCon.

What's harder to find is the next layer: what happens to a sample after it's published. Connecting a live Zenoh network to something persistent and queryable usually means working around the limits of Zenoh's existing storage options.

This post shows another way. By the end you'll have a Python publisher sending data over Zenoh, a storage backend persisting it automatically, and a query client pulling exact time ranges back out, all without a custom backend or a bridge process.

ReductStore 1.20.0 is now available. This release adds lifecycle policies for automated retention and compression, expands Protobuf support across the ingestion and query ecosystem, and brings SQL and Parquet workflows to the ReductSelect extension.

To download the latest release, visit the Download Page.

What's new in 1.20.0?​

The first major change in v1.20 is lifecycle policies. ReductStore can now run background tasks that delete or compress old records based on age, entry names, and optional label conditions. This makes retention and storage-efficiency rules part of the database configuration instead of an external cleanup script.

The second major change is Protobuf support across the ecosystem. ReductBridge can ingest Protobuf payloads from MQTT, extract labels from message fields, and store schema metadata as a $schema entry attachment. ReductSelect can then use the same attachment to decode records and run SQL over the decoded fields.

The release also extends ReductSelect with SQL processing for structured records and Parquet support for analytics-oriented pipelines. You can query CSV, JSON, Protobuf, and Parquet records with the same ENTRY() table function and export selected results as Parquet files.

You deployed ten robots. The system worked. Now you have a hundred, and your engineering team is complaining about things that didn't exist six months ago: storage filling up on edge devices, cloud bills growing faster than the fleet, retraining cycles that take weeks instead of days, and incident investigations lack the data they need.

This is a predictable consequence of crossing a scaling threshold that almost every AMR operator hits.