---
title: " Physical AI Telemetry: A Database Architecture"
description: " AV fleet telemetry (vehicle state, disengagement events, mission data) is a time-series workload. Raw sensor data is not. See the schema and SQL."
section: "Postgres for IoT"
---
> **TimescaleDB is now Tiger Data.**
## 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](https://www.tigerdata.com/blog/great-models-arent-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](https://github.com/ros2/rosbag2/issues/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](https://www.tigerdata.com/learn/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](https://www.tigerdata.com/learn/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](https://www.tigerdata.com/docs/learn/continuous-aggregates) 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](https://www.tigerdata.com/learn/postgresql-extensions-postgis), 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](https://www.tigerdata.com/docs/learn/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](https://www.tigerdata.com/learn/fleet-telemetry-database) |
| Robot / AMR fleets | Battery, pose, mission/task status, fault codes | [Robot Fleet Telemetry](https://www.tigerdata.com/learn/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**](https://www.tigerdata.com/learn/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**](https://www.tigerdata.com/learn/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.