---
title: "Robot Fleet Telemetry: Database Architecture"
description: "A schema for robot fleet telemetry: battery, pose, mission status, and fault codes as a time-series workload, plus what not to store in Postgres."
section: "Postgres for IoT"
---
> **TimescaleDB is now Tiger Data.**
## Introduction
This page provides a dedicated look at robot fleet telemetry. It covers structured fleet-health telemetry: battery and state-of-charge readings, position and pose, mission and task status, fault and error codes, and uptime, from AMRs, industrial robot arms, and service robots like [Tailos's Rosie robot vacuum](https://www.tigerdata.com/case-studies/tailos). It does not cover raw perception data: camera frames, LiDAR point clouds, rosbag recordings. That's a data-lake and object-storage problem, covered in its own section below. It also doesn't cover autonomous vehicles or robotaxis, a related but distinct telemetry profile discussed at a category level in [Great Models Aren't Enough for Physical AI](https://www.tigerdata.com/blog/great-models-arent-enough-for-physical-ai).
The thesis in one sentence: don't use Postgres for your rosbag or point-cloud data; do use it for everything else your robot fleet reports.
This is the same architectural pattern documented in [Tiger Data's fleet telemetry database guide](https://www.tigerdata.com/learn/fleet-telemetry-database), applied to robots instead of vehicles: a narrow-row hypertable for continuous signals, standard relational tables for fleet metadata, and continuous aggregates for the dashboards that fleet operators actually look at.
Tiger Data builds Tiger Cloud, one of the databases discussed here. The perception-data section and the decision framework both cover cases where a different tool is the right call.
## What is robot fleet telemetry data?
Robot fleet telemetry data is the structured, timestamped operational data an AMR, industrial robot, or service robot reports for fleet-health monitoring: battery and state-of-charge readings, position and pose, mission and task status, fault and error codes, and uptime. It excludes raw perception data like camera frames and LiDAR point clouds, which belongs in object storage instead.
Three robot categories generate this telemetry:
- **AMRs**: autonomous mobile robots that navigate warehouse and logistics floors, from vendors like Locus, MiR, and OTTO
- **Industrial robots**: fixed-base robotic arms on a factory floor, reporting joint and motor diagnostics rather than navigating open space
- **Service robots**: consumer- and commercial-facing robots, like Tailos's Rosie robot vacuum, deployed across hotels and multifamily residences
A modern fleet across any of these categories produces five primary structured data types:
- **Battery / state-of-charge (SoC)**: charge percentage, voltage, current draw, and charge-cycle counts. Continuous while operating, higher-frequency during charging.
- **Position / pose**: for AMRs and mobile service robots, this is typically local map-frame coordinates (x, y, theta) from SLAM or odometry, not GPS latitude and longitude. That's a real difference from the vehicle-fleet anchor's PostGIS/GPS model. Outdoor AMRs with GPS receivers are the exception, not the default.
- **Mission / task status**: current task ID, task state (queued, in progress, complete, failed), and assigned zone or destination.
- **Fault / error codes**: motor stalls, sensor dropouts, collision-avoidance triggers, e-stop events. Event-style, not continuous.
- **Uptime / health**: operational hours, idle time, duty cycle, and joint or motor diagnostics for industrial arms.
Every one of those records shares the same time-series profile: timestamped at collection, append-only, and queried almost exclusively by time range: "show me this robot's battery drain over its last shift."
The cardinality problem shows up the same way it does on the vehicle side. robot_id is the high-cardinality dimension, and it grows with fleet size, not with time. A 200-robot warehouse fleet reporting battery, pose, and task status at 1 Hz sits at a comparable ingestion profile to the smaller vehicle-fleet examples on the [fleet telemetry database guide](https://www.tigerdata.com/learn/fleet-telemetry-database): the same math applies, just with robots instead of vehicles.
## What NOT to store here: perception data
It's worth stating plainly: raw camera frames, LiDAR point clouds, and full rosbag or rosbag2 recordings are a data-lake and object-storage problem. No relational database, including Tiger Data, should try to own that workload.
A category of tooling exists specifically for this: purpose-built time-series object stores and robotics data-management platforms built to handle camera and LiDAR streams at fleet volume. That tooling is the right fit for that slice of the workload.
Structured, timestamped, append-only fleet-health signals, the five data types above, belong in a database like Tiger Cloud. Multi-gigabyte-per-minute binary sensor streams belong in object storage or a purpose-built robotics data platform. Conflating the two is the most common architecture mistake teams make in this space.
## The ROS 2 / rosbag2 storage gap
There's a real, verifiable gap here, and it's worth citing directly. GitHub issue [ros2/rosbag2 #1739](https://github.com/ros2/rosbag2/issues/1739), "Support for Time-Series Database and H.264 Encoding," was filed in July 2024 and is still open as of this writing. It explicitly names TimescaleDB and InfluxDB as candidate backends, with no implemented integration.
Our own [Matty Stratton](https://www.tigerdata.com/blog/author/matty) wrote about hitting this exact gap, in ["Why I'm Learning ROS 2 as a Database Person"](https://dev.to/mattstratton/why-im-learning-ros-2-as-a-database-person-3cce): there's no real story for storing and querying ROS 2 telemetry at fleet scale once the pilot robot becomes a fleet. That's the practitioner's-eye view of the same gap the GitHub issue documents from the maintainer side.
The default ROS 2 recorder writes to a SQLite3-backed rosbag2 file, a reasonable format for a single robot, single recording session: capture everything, replay it later, debug an incident. It was never built for fleet-wide, long-term, cross-robot querying. A single-session file format has no answer for "show me every robot that threw this fault code last week," because that question spans files, robots, and time ranges the format doesn't index against.
Tiger Data's answer here is a straight one: this page doesn't claim to solve rosbag storage. It shows how to store everything around the rosbag, the structured telemetry fleet operators actually query, in a database built for exactly that shape of data, while pointing to purpose-built tooling for the binary and perception slice.
## Why robot fleet telemetry is a time-series workload
The case here follows the same shape as the [fleet telemetry database guide's](https://www.tigerdata.com/learn/fleet-telemetry-database) argument for vehicles, adapted to robots.
Without time-based partitioning, a growing fleet's telemetry table forces sequential scans that grow linearly with history, even when a dashboard query only needs the last hour. robot_id as a high-cardinality index dimension causes index bloat and write amplification in a general-purpose RDBMS as fleet size grows.
There's a compression opportunity specific to how robots operate: idle robots (charging, queued, powered down between shifts) send long runs of near-identical readings, exactly the temporal redundancy that columnar compression on a sorted time column is built to exploit.
There's also an aggregation problem at dashboard-query time. Fleet-health dashboards need rollups like "average battery drain per robot per shift" or "fault count per robot type per day." Without pre-computed aggregates, every dashboard load rescans raw telemetry from scratch.
None of this matters at small scale. A handful of robots at low frequency runs fine on plain PostgreSQL. The architecture question shows up at fleet scale, tens to hundreds of robots and up, the same threshold as the vehicle side.
## Schema design for robot fleet telemetry
The schema splits into three tables, one more than the vehicle-fleet anchor's two-table model. Robots need a dedicated events table for fault codes and mission/task-status transitions, separate from the continuous numeric signals table for battery, SoC, and joint diagnostics. Fault codes and task states are discrete and categorical, and forcing them into a `DOUBLE PRECISION value` column the way the numeric telemetry table does would be the wrong fit for data without a meaningful average or trend line.
Robot metadata is a standard relational table:
`-- Robot metadata (standard relational table)
CREATE TABLE robots (
robot_id TEXT PRIMARY KEY,
robot_type TEXT, -- 'amr', 'industrial_arm', 'service'
model TEXT,
site TEXT,
fleet_group TEXT
);`
Continuous numeric telemetry (battery, SoC, pose, joint diagnostics) is a narrow-row hypertable:
`-- Continuous numeric telemetry (time-series)
CREATE TABLE robot_telemetry (
time TIMESTAMPTZ NOT NULL,
robot_id TEXT NOT NULL REFERENCES robots(robot_id),
signal TEXT NOT NULL, -- 'battery_pct', 'soc_pct', 'pose_x', 'pose_y', 'pose_theta', etc.
value DOUBLE PRECISION NOT NULL
);
SELECT create_hypertable('robot_telemetry', by_range('time'));
ALTER TABLE robot_telemetry SET (
timescaledb.enable_columnstore,
timescaledb.compress_orderby = 'time DESC',
timescaledb.compress_segmentby = 'robot_id, signal'
);
CALL add_columnstore_policy('robot_telemetry', after => INTERVAL '7 days');`
Discrete events (fault codes and mission/task-status transitions) get their own hypertable:
`-- Discrete events: fault codes, mission/task status transitions
CREATE TABLE robot_events (
time TIMESTAMPTZ NOT NULL,
robot_id TEXT NOT NULL REFERENCES robots(robot_id),
event_type TEXT NOT NULL, -- 'fault', 'task_status', 'e_stop', etc.
code TEXT, -- fault code or task state value
severity TEXT, -- 'info', 'warning', 'critical' (nullable for task_status rows)
message TEXT
);
SELECT create_hypertable('robot_events', by_range('time'));`
A continuous aggregate powers the fleet-health dashboard, rolling up uptime, fault counts, and average battery drain per robot per day without rescanning raw telemetry on every load:
`CREATE MATERIALIZED VIEW robot_fleet_health_daily
WITH (timescaledb.continuous) AS
SELECT
time_bucket('1 day', time) AS day,
robot_id,
AVG(value) FILTER (WHERE signal = 'battery_pct') AS avg_battery_pct,
MIN(value) FILTER (WHERE signal = 'battery_pct') AS min_battery_pct
FROM robot_telemetry
GROUP BY day, robot_id
WITH NO DATA;
SELECT add_continuous_aggregate_policy('robot_fleet_health_daily',
start_offset => INTERVAL '3 days',
end_offset => INTERVAL '1 hour',
schedule_interval => INTERVAL '1 hour'
);`
A second continuous aggregate, rolling up daily fault counts by `event_type` and `severity` from `robot_events`, follows the same pattern and can be added as monitoring needs grow. See the [continuous aggregates documentation](https://www.tigerdata.com/docs/learn/continuous-aggregates) for the full reference.
One note for fleets that mix indoor and outdoor robots: if yours includes outdoor AMRs reporting GPS instead of local map-frame coordinates, the vehicle-fleet anchor's PostGIS `GEOMETRY(Point, 4326)` pattern applies directly. There's no need to re-derive it here; the [fleet telemetry database guide's](https://www.tigerdata.com/learn/fleet-telemetry-database) geospatial section covers it.
## Robot fleet health monitoring and predictive maintenance
This is the same predictive-maintenance approach Tiger Data enables for IIoT customers, applied to robot fleets as robot observability: fleet-health monitoring built on the schema above rather than a separate architecture.
The `robot_fleet_health_daily` continuous aggregate is the building block. A trending decline in `avg_battery_pct` over weeks signals battery degradation before it causes a failed shift. Fault-code frequency by `robot_id` in `robot_events` surfaces robots trending toward a breakdown before it takes them offline.
For the fuller treatment of this pattern outside robotics, see [IIoT database requirements for predictive maintenance](https://www.tigerdata.com/learn/iiot-database-requirements) (background on industrial IoT concepts: [A Beginner's Guide to IIoT and Industry 4.0](https://www.tigerdata.com/learn/a-beginners-guide-to-iiot-and-industry-4-0)).
## Real-world proof: Tailos and the Rosie robot vacuum
[Tailos](https://www.tigerdata.com/case-studies/tailos), based in Austin, builds AI-powered robotics for the hospitality industry. Its flagship product, Rosie, is an intelligent robot vacuum deployed across hotels and multifamily residences to automate floor cleaning.
Before working with Tiger Data, Tailos ran on Google Cloud services and struggled with data latency and the complexity of managing multiple databases as its telemetry volume grew. Moving to Tiger Cloud let Tailos efficiently handle large volumes of telemetry data, providing real-time insights into robot performance and customer usage.
## Choosing a database for robot fleet telemetry: decision framework
Below are decision framework guidelines that can help make the call for selecting a database for your fleet.
**Choose Tiger Cloud if:**
- You want one database for structured telemetry, robot metadata, and fault/event logs instead of stitching together separate systems
- You need SQL joins between telemetry and robot fleet metadata without ETL
- You want continuous aggregates for fleet-health dashboards without a scheduled batch job
- Your team already runs Postgres elsewhere and wants to avoid adding a new database just for robotics telemetry
**Choose InfluxDB if:**
- Your team is already invested in the InfluxDB ecosystem (Telegraf, Flux/InfluxQL) and migration cost outweighs the benefit of SQL joins to fleet metadata
Note: Be aware that [InfluxDB version fragmentation](https://docs.influxdata.com/influxdb3/which-influxdb-3/) (1.x vs. 2.x vs. 3.0 APIs, Cloud Serverless vs. Cloud Dedicated) is a real operational risk
**Choose a purpose-built robotics data platform if:**
- Your primary storage problem is camera, LiDAR, or full rosbag/rosbag2 recordings. This isn't a workload any generic relational database should try to own. ReductStore- and MCAP-style tooling exists specifically for this category.
**Don't use Tiger Data if:**
- The core workload is raw perception and sensor-stream storage (see above). Route that to object storage or a robotics-native data platform instead.
- The team needs a drop-in replacement for the ROS 2/rosbag2 recorder itself. Tiger Data complements that layer; it doesn't replace it.
## Migrating to Tiger Data
Teams tend to arrive at this architecture from one of three starting points.
**From the default ROS 2 SQLite3 recorder.** Teams outgrow single-session, single-robot rosbag files once they need fleet-wide, long-term queries. The path is exporting or streaming structured telemetry into the schema above, alongside continued rosbag2 use for perception data.
**From a NoSQL/document store fleet log.** Teams using MongoDB or similar for flexible-schema event logs gain SQL joins to fleet metadata and continuous aggregates by moving structured telemetry to Tiger Cloud.
**From self-managed PostgreSQL without hypertables.** Teams already on Postgres hitting sequential-scan and index-bloat problems at fleet scale adopt hypertables and columnstore compression incrementally, without a database migration.