Home Alternatives Time-series basics Data Center & Infrastructure Telemetry Postgres basics Postgres guides Postgres best practices

Robot Fleet Telemetry: Database Architecture for AMR, Industrial Robot, and Service Robot Data

By Tiger Data Team

Updated at Jul 8, 2026

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. 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.

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: 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, "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.

Why robot fleet telemetry is a time-series workload

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.

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 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.

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 (background on industrial IoT concepts: A Beginner's Guide to IIoT and Industry 4.0).

Real-world proof: Tailos and the Rosie robot vacuum

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 (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.

FAQ

What database can I use to store robotics-based sensor data?

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.

How do I store and query ROS 2 robot telemetry data over time?

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.

What's the best way to store battery, position, and mission data for a fleet of autonomous mobile robots?

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.

How do I build a database for robot fleet health monitoring and predictive maintenance?

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.

What database should I use for high-frequency robot sensor data if I still need SQL joins to fleet metadata?

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.

How do I store rosbag or ROS 2 telemetry data long-term instead of relying on the default SQLite3 recorder?

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.

Can PostgreSQL handle robot fleet telemetry at scale?

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.

What's the difference between storing rosbag/camera data and storing robot fleet health data?

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.

What database do industrial robots and AMRs use for fleet management data?

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.

How is robot fleet telemetry different from vehicle fleet telemetry?

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.

Is Tiger Cloud or TimescaleDB a good fit for ROS 2 robotics data?

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.

Evaluate the database company Tiger Data on robot fleet telemetry.

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.