A rosbag recording is ultimately written to files, and a single file cannot grow forever. Something has to close it at some point, so rosbag2 makes you pick: ros2 bag record -a -b 100000 closes one every 100 kilobytes, or -d 9000 closes one every 9000 seconds. Either way, a recording that runs for hours comes out as a directory of many small files instead of one huge file that becomes awkward to work with.

Splitting a recording into five minute bags seems like a simple solution. The problem starts when you need to turn them back into one file.

A rosbag2 user reported that merging 300 GB of split recordings required roughly 600 GB of disk capacity. The original 300 GB stays on disk while another 300 GB is written out as the merged bag.

Splitting solves one problem. Merging creates another, and it is easy to underestimate.

We originally built ReductStore to store data on edge devices and read it back by time interval. But a device only has so much disk space. With cameras and sensors writing all the time, we used a FIFO quota to remove the oldest records and make room for new ones. That left us with another problem: how to get the data off the device before it was deleted.

At first, transferring data from an edge device to central storage was a manual job. We used the CLI client or scripts and copied data when somebody remembered to do it. It was always problematic because data collection never stopped. Sometimes we had only two or three days to copy it before it was gone, and a temporary network problem or a missed run could make that window disappear completely.

Automatic replication was the next logical step. The edge is producing a stream of new data, while the central store has more capacity and can have different criteria for what it keeps. We needed to forward new records and configure source-side filters for each destination. Keeping two identical replicas was not the goal.

We also had to keep in mind that the source is usually on the edge. Very often it has no public IP address, and its network connection can be unstable, slow, or absent for long periods. Replication therefore could not make local ingestion wait for the central store. The device still needed to accept data first and deliver it later when a connection became available.

ReductStore 1.21.0 is now available. This release brings the new Data Explorer to the Web Console and delivers many improvements to data replication, lifecycle policies, queries, and system diagnostics.

ReductStore v1.21 also reflects an important change in how the project is developed. Since moving ReductStore Core to the Apache License 2.0 in v1.19, the community has become an important part of the development process. This release cycle brought together 16 contributors across ReductStore, ReductStore CLI, and the Web Console.

To download the latest release, visit the Download Page.

What's new in 1.21.0?​

The main user-facing change is the new Data Explorer in Web Console v1.17.2. It provides a visual interface for building conditional queries, sampling and limiting results, and configuring ReductROS and ReductSelect processing steps without writing the complete JSON query by hand.

Replication is now more flexible and efficient. A replication task can add a prefix to destination entry names, compress batch transfers with gzip or zstd, and use path-aware entry patterns with *, **, and exclusions. Lifecycle policies and regular queries use the same entry-pattern syntax, making filters consistent across the database.

The release also expands diagnostics in the $system bucket, adds bounded processing windows for lifecycle policies, and improves replication throughput and reliability.