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

Physical AI Telemetry: Database Architecture for Autonomous-Vehicle Fleets

Physical AI Telemetry: A Database Architecture for Autonomous-Vehicle Fleets

By Tiger Data Team

Updated at Jul 20, 2026

Introduction

"Physical AI" gets used two ways right now: as a real technical category and as a hype-cycle label slapped on anything with a motor and a model. Both are true at once, and it's worth saying that plainly before making any claim about it.

The skepticism is fair. But autonomous-vehicle fleets are already running commercial operations at meaningful scale, not lab demos. Waymo alone has passed tens of millions of paid robotaxi rides. That's a real deployment footprint, whatever you think of the term describing it.

This page is about one narrow question inside that category: the database architecture for the structured telemetry an autonomous-vehicle or robotaxi fleet produces. Vehicle state, health, disengagement events, mission and trip data. It is not about the raw sensor and perception stack, which is a different problem with a different answer.

One more thing upfront: Tiger Data sells a database, so this page has a stake in the answer. The argument here is where a time-series database fits in an AV data stack, and just as importantly, where it doesn't. Tiger Data's Great Models Aren't Enough for Physical AI makes the broader case that real-world Physical AI deployment is gated by data, safety, and operations, not model quality alone. This page picks up the data half of that argument and gives it a schema.

The line between raw perception data and operational telemetry

Raw perception data, camera frames, LiDAR point clouds, radar returns, is a data-lake problem. So are full rosbag2 or MCAP recordings kept for simulation replay and model training, and the scenario and validation datasets (OpenSCENARIO, OpenDRIVE) that ADAS validation tooling consumes. Tiger Data does not solve for any of that, and this page isn't going to pretend otherwise.

The scale involved is not abstract. Public reporting on large AV fleet operations puts a single autonomous vehicle's raw sensor output at tens of terabytes per day. That's the data-lake side of this problem, and it's enormous by any measure. It is not Tiger Data's claim to make.

What's left over is smaller and shaped differently: vehicle state and health channels, disengagement and safety-driver-intervention events, mission and trip metadata and location, and the fleet-wide operational KPIs computed from all of it. That slice is discrete, timestamped, and structured, and it's what the rest of this page covers.

Here's the rule of thumb to apply on your own: if it's a continuous stream of raw sensor bytes headed for a model or a replay tool, it's data-lake-shaped. If it's a discrete, timestamped, structured fact about vehicle or fleet state, it's time-series-shaped.

Autoware, ROS 2, and the telemetry storage gap

Autoware is the concrete example this page argues from, not an abstract "AV company." It's an open-source, ROS 2-based, Tier4-founded autonomous-driving stack, and it's a working reference for where the storage question actually shows up in a driving stack.

The gap is documented, not theoretical. GitHub issue ros2/rosbag2 #1739 is developers on the ROS 2 project explicitly asking for a queryable time-series storage backend instead of the file-based default recorder. That request has been open since 2024.

The storage format itself is mid-transition. rosbag2 has historically defaulted to SQLite3, and Autoware's own published sample bags still ship as SQLite3 .db3 files. MCAP is available as a rosbag2 storage plugin and is increasingly adopted for new recordings. Call it SQLite3-backed, increasingly MCAP-based, rather than treating SQLite3 as the unqualified current default.

Neither format closes the gap GitHub issue #1739 describes. SQLite3 and MCAP are both file-based recording formats built for full-fidelity playback and simulation, not a queryable operational store for the structured telemetry slice. Tiger Data's robot fleet telemetry guide covers this storage gap in depth for AMRs and industrial robots on generic ROS 2 topics; the same ROS 2 storage gap documented for robot fleets applies directly to Autoware-based AV stacks. What's specific to AV is the layer sitting on top of those generic ROS 2 topics: Autoware's planning, control, and localization state, and the AV-specific events covered below.

What's actually time-series-shaped in an autonomous-vehicle fleet

Four data types make up the operational telemetry slice. Each is timestamped, append-only, and queried by time range in practice: vehicle state and health telemetry, disengagement and safety-driver-intervention events, mission and trip telemetry, and fleet-wide operational KPIs.

Vehicle state and health telemetry

Most AV fleets run on EV platforms and share the same health channels covered on Tiger Data's fleet telemetry database guide for human-driven fleets: battery state of charge and state of health, tire pressure, brake wear, thermal telemetry. That guide's EV and OBD-II schema pattern applies here without modification, so it's not re-derived below.

A compact hypertable covers the core signals:

CREATE TABLE vehicle_state (
    time            TIMESTAMPTZ      NOT NULL,
    vehicle_id      TEXT             NOT NULL,
    battery_soc     DOUBLE PRECISION,
    battery_soh     DOUBLE PRECISION,
    tire_pressure   DOUBLE PRECISION,
    brake_wear_pct  DOUBLE PRECISION
);

SELECT create_hypertable('vehicle_state', by_range('time'));

A time-bounded query against it looks like any other fleet telemetry query:

SELECT vehicle_id, time, battery_soc, brake_wear_pct
FROM vehicle_state
WHERE time > NOW() - INTERVAL '24 hours'
ORDER BY vehicle_id, time;

Disengagement and safety-driver intervention events

This is the single most AV-specific data type on this page, and the clearest differentiator against both sibling telemetry profiles. Human-driven fleets have no equivalent concept. Robot fleets have fault and task-status events, but nothing regulatory tied to a human taking over from an autonomous system.

A disengagement is any point where a safety driver or remote operator takes control from the autonomous system, whether planned (a test protocol checkpoint) or unplanned (a system limitation or edge case the stack couldn't handle).

Model it as an append-only event table, not a counter:

-- disengagement_events uses a PostGIS geometry column, so enable PostGIS first:
CREATE EXTENSION IF NOT EXISTS postgis;

CREATE TABLE disengagement_events (
    time             TIMESTAMPTZ NOT NULL,
    vehicle_id       TEXT        NOT NULL,
    trigger_reason   TEXT,       -- 'planned_test', 'perception_limit', 'planner_fault', 'operator_override'
    duration_seconds INT,
    location         GEOMETRY(Point, 4326)
);

SELECT create_hypertable('disengagement_events', by_range('time'));

Disengagement rate, disengagements per 1,000 miles or per operating hour, is one of the standard ways AV fleet operators and regulators track system maturity over time. That makes it a rollup, not just a log, and a continuous aggregate is the right tool for computing it without rescanning raw events on every query:

CREATE MATERIALIZED VIEW disengagement_rate_daily
WITH (timescaledb.continuous) AS
SELECT
    time_bucket('1 day', time) AS day,
    vehicle_id,
    COUNT(*) AS disengagement_count
FROM disengagement_events
GROUP BY day, vehicle_id
WITH NO DATA;

Mission and trip telemetry

Trip-level data covers mission start and end, route, pickup and dropoff events for robotaxi operations, and GPS or location data captured throughout the trip. The geospatial pattern is already established on Tiger Data's PostGIS and Timescale geospatial guide, including the GEOMETRY(Point, 4326) column type and spatial indexing needed for geofencing and trajectory queries. That pattern applies directly to trip and mission data and isn't re-derived here.

Fleet-wide operational KPIs

Fleet operators track rollup metrics across everything above: uptime, utilization, disengagement rate, energy consumption per mile, and average battery health trend across the fleet. None of these are single-table queries. A "disengagement rate this week vs. last week" dashboard needs to join event counts against mileage or operating hours pulled from mission telemetry, then group by vehicle or by fleet segment.

That join-and-rollup pattern is a continuous-aggregate use case in the same way the disengagement rate rollup above is: pre-computed on a schedule, so a dashboard load reads a summary table instead of re-scanning raw event and state tables every time someone opens it. At fleet scale, hundreds of vehicles reporting state at 1 Hz plus a steady trickle of event rows, that difference is the gap between a dashboard that loads in milliseconds and one that times out. Tiger Data's documentation on continuous aggregates covers the mechanism in full.

Physical AI telemetry vs. robot fleet telemetry vs. human-driven fleet telemetry

Three sibling pages, three operator types, one underlying pattern. Here's how to tell which one is actually for you:

Operator type	Most distinctive time-series data	Anchor page
Human-driven fleets	GPS, OBD-II, CAN bus	Fleet Telemetry Database
Robot / AMR fleets	Battery, pose, mission/task status, fault codes	Robot Fleet Telemetry
AV / robotaxi fleets	Vehicle state and health, plus disengagement events	This page

All three share the same underlying architecture: a narrow-row hypertable for continuous signals, standard relational tables for fleet metadata, and continuous aggregates for the rollups fleet operators actually look at. What's distinct about this page is disengagement events, which neither sibling profile has an equivalent for, and a sharper data-lake/time-series boundary, given how much raw perception data an AV fleet also produces alongside its structured telemetry.

Decision framework

Choose a time-series database (Tiger Data) for the operational telemetry slice if: you need to query vehicle state, health, disengagement events, or mission and trip data in real time or over historical windows, and you want SQL-native joins against fleet metadata.

Choose a data lake or object storage, not a time-series database, if: you're storing raw camera, LiDAR, or radar streams, or full rosbag2/MCAP recordings for simulation replay and model training. That's not a workload a relational time-series database should take on.

Use the robot fleet telemetry pattern instead if: your fleet is AMRs, industrial robots, or service robots rather than licensed, road-going autonomous vehicles.

Use the fleet telemetry database pattern instead if: your vehicles have a human driver. The telemetry shape (GPS, OBD-II, CAN bus) is closely related but doesn't include disengagement events or an autonomy stack.

Migrating to a queryable telemetry store

Most teams arrive at this architecture from one of three starting points.

From the ROS 2/rosbag2 default recorder alone. Teams that treated rosbag2 files as their only telemetry record hit the wall GitHub issue #1739 describes: no way to query vehicle state or disengagement history without replaying files. The fix isn't replacing rosbag2, which is still needed for full-fidelity recording. It's adding a queryable store for the structured slice alongside it.

From ad hoc object-storage exports with no query layer. Teams dumping structured telemetry into flat files in the same bucket as raw sensor data typically hit this wall when they need a real-time operational dashboard, fleet uptime, disengagement rate, rather than periodic batch analysis.

From a general-purpose NoSQL store. Teams outgrow a document store for disengagement or mission logs once they need relational joins against maintenance, quality, or trip-metadata tables. A document store handles a single disengagement record fine; it doesn't handle "join every disengagement this month to the vehicle's maintenance history and current software version" without application-side stitching. That's the same pattern covered in more depth on the sibling pages linked throughout this one.

None of these migrations require giving up on rosbag2, MCAP, or object storage for the perception side. The queryable store sits alongside them, handling the slice of telemetry that fleet operations, safety teams, and regulators actually query day to day.

FAQ

What database should I use for autonomous vehicle or robotaxi fleet telemetry?

A time-series database, such as Tiger Data on Tiger Cloud, for the structured telemetry slice: vehicle state, health, disengagement events, mission and trip data. Pair it with object storage or a data lake for raw sensor recordings.

Isn't autonomous vehicle data all LiDAR and camera frames?

Partly true. Raw perception data is enormous and is a real data-lake problem. But every AV fleet also produces a smaller, structured, timestamped slice, vehicle state, disengagement events, mission data. That's a time-series workload with its own architecture question.

Can PostgreSQL or TimescaleDB store ROS 2 or Autoware telemetry data?

Yes, for the structured and operational slice, not for raw rosbag2 or MCAP recordings, which stay file-based.

What's the difference between AV fleet telemetry, robot fleet telemetry, and human-driven fleet telemetry?

All three share a hypertable-plus-relational-metadata-plus-continuous-aggregates pattern. What differs is the data shape: disengagement events for AVs, fault and task-status events for robots, OBD-II and CAN bus signals for human-driven fleets.

How do you store disengagement and safety-driver intervention events?

As an append-only event table with a trigger reason, duration, and location per row, rolled up into a disengagement-rate continuous aggregate rather than recomputed from raw events on every query.

Is 'Physical AI' just hype, or is there a real database architecture question underneath it?

Both. The term gets used as a hype-cycle label as much as a technical category. But the underlying question, where structured AV telemetry lives separate from raw perception data, is real, and most current Physical AI content doesn't answer it.

What is Autoware, and how does it relate to ROS 2?

Autoware is an open-source, Tier4-founded autonomous-driving stack built on ROS 2, used here as a concrete example instead of an abstract AV company.

Does ROS 2's rosbag2 use a queryable database format?

No. rosbag2 has historically defaulted to SQLite3, with MCAP increasingly adopted as an alternative storage format, but both are file-based recording formats, not a queryable operational store.

How much data does an autonomous vehicle actually generate?

Public reporting on large AV fleet operations puts raw sensor output at tens of terabytes per vehicle per day. Almost none of that volume is the structured telemetry slice this page covers.

How do you calculate fleet-wide disengagement rate from telemetry data?

Roll up disengagement events by vehicle or fleet over a rolling mileage or time window using a continuous aggregate, rather than recomputing the rate from raw events on every dashboard load.

Should raw sensor data (LiDAR, camera, radar) live in the same database as vehicle telemetry?

No. Raw perception data belongs in object storage or a data lake built for that access pattern. Vehicle state, health, and event data belongs in a time-series database built for structured, timestamped queries.

What's the difference between simulation/training data and operational fleet telemetry?

Scenario and validation datasets and full rosbag2/MCAP recordings are used for simulation replay and model training and are data-lake-shaped. Live operational telemetry is time-series-shaped and queried in near-real-time by fleet operations.