By Tiger Data Team
Updated at Jul 8, 2026
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. 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.
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, 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.
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: the same math applies, just with robots instead of vehicles.
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.
There's a real, verifiable gap here, and it's worth citing directly. GitHub issue ros2/rosbag2 #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 wrote about hitting this exact gap, in "Why I'm Learning ROS 2 as a Database Person": 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.
The case here follows the same shape as the fleet telemetry database guide's 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.
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 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 geospatial section covers it.
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 (background on industrial IoT concepts: A Beginner's Guide to IIoT and Industry 4.0).
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.
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 (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.
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.
A time-series database is the right foundation for the structured side of robotics data. Battery, position, mission status, and fault codes are timestamped, append-only, and queried by time range. Tiger Cloud (PostgreSQL plus TimescaleDB) handles this with full SQL and continuous aggregates for fleet dashboards.
Separate the two data shapes. Structured telemetry (battery, pose, task status, faults) goes into a time-series database like Tiger Cloud, modeled with a narrow-row hypertable and an events table. Raw rosbag2 and perception data stays in rosbag2 files or a purpose-built robotics data platform. Don't try to replace the ROS 2 recorder itself.
Model battery/SoC and pose as narrow-row numeric signals (time, robot_id, signal, value) in a hypertable. Model mission/task status and fault codes as discrete events in a separate events table.
A continuous aggregate over the telemetry hypertable, rolling up daily battery trend and fault-count trend per robot, is the core building block. It flags degrading batteries and fault-prone robots before failure, without a separate batch job.
Tiger Cloud. Hypertables handle the high-frequency, high-cardinality telemetry writes, while standard relational tables for robot metadata join to it with regular SQL, with no ETL between systems.
The SQLite3-backed rosbag2 recorder is built for single-session, single-robot capture, not fleet-wide long-term querying. There's no drop-in database replacement for it today; GitHub issue ros2/rosbag2 #1739 is the open, unresolved request for one. Keep rosbag2 for perception data and stream structured telemetry into a time-series database in parallel.
Standard PostgreSQL without time-series extensions runs into sequential-scan growth and index bloat as robot_id cardinality grows. TimescaleDB adds hypertables, columnstore compression, and continuous aggregates that address those bottlenecks. Tiger Cloud is the managed version of that same engine.
Rosbag, camera, and LiDAR data is large, binary, and mostly write-once, read-rarely: a data-lake and object-storage problem. Fleet health data (battery, pose, faults) is small, structured, and queried constantly by time range and robot: a database problem.
Fleet-orchestration platforms (routing, task queuing) are separate from the database question. For the underlying structured telemetry, battery, pose, task status, and faults, a time-series database is the common architectural answer regardless of which orchestration platform sits on top.
Architecturally, nearly identical. Both are timestamped, high-cardinality, append-only structured data best modeled as a hypertable with relational metadata. The practical difference: robots typically report local map-frame coordinates (SLAM/odometry) rather than GPS latitude and longitude, and robot fleets add mission/task status as a first-class event type.
Yes, for the structured telemetry side: battery, pose, faults, mission status. Not as a replacement for rosbag2 or perception-data storage. TimescaleDB is the open-source engine; Tiger Cloud is the managed service running it.
Tiger Data (formerly Timescale) builds Tiger Cloud, a managed PostgreSQL service with TimescaleDB's time-series extensions: hypertables, columnstore compression, and continuous aggregates. It's a credible fit for structured robot fleet telemetry specifically, and it doesn't attempt to solve rosbag2 or perception-data storage.