Alexey Timin

InfluxDB works well for robotics metrics such as battery level, temperature, CPU usage, detection counts, and anomaly scores. These numeric values are a good fit for dashboards, alerts, and time-series analytics.

Robots also generate much heavier data: camera frames, LiDAR scans, audio, and high-frequency waveform chunks. This raw data must often be preserved in its original format for incident replay, debugging, and model training.

You do not need to replace InfluxDB. Keep it for the metrics you need to visualize and analyze, and add ReductStore for the raw sensor data. Use the same event time and stable robot and sensor identifiers in both systems so a metric can be traced back to the original records.

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.

MQTT is a common choice for the communication stack in IoT and robotics applications because it is lightweight and easy to integrate. But many of those applications do not send only small JSON telemetry messages. They also publish JPEG frames, vibration waveforms, audio clips, protobuf messages, and other binary payloads that need to be stored and queried later.

This is where a regular MQTT broker or a traditional time-series database starts to fall short. Brokers are designed for message delivery, not long-term historical storage, and many databases either expect structured numeric fields or make it hard to keep large binary records tied to accurate timestamps.

In this tutorial, we will use ReductBridge to subscribe to MQTT topics and write the raw binary payloads into ReductStore with a time index. This lets you keep camera frames and sensor payloads as they are, while still querying them by time range, labels, and entry name for replay, debugging, and offline analysis.