具身机器人里"数据库"其实分四层

具身机器人没有"一个数据库包打天下"的说法，它的数据是分层的，每层用的存储形态完全不同：

1. 训练数据集层（最核心，也最该关注）

这一层严格说不叫"数据库"，而是‌数据集格式 + 文件存储‌，但它是具身AI的命脉。目前事实标准有三条：

LeRobot 格式‌：Hugging Face 社区主推，目前是机器人微调最流行的容器。用 ‌Parquet 存动作/状态‌、用 ‌MP4 存多摄像头视频‌，配 info.json / stats.json 元信息。原生支持 ACT、Diffusion Policy 训练。

RLDS 格式‌：基于 TFRecords 风格，‌Open X-Embodiment（OXE）‌ 和 Octo、RT-2 等大项目采用，跨本体训练的数据交换协议。

HDF5 / Zarr 格式‌：层次化、支持分块随机访问，适合作为‌原始采集的"唯一真源"‌，不受单一格式锁定。

业界推荐的做法是：‌采集阶段用 HDF5 存源数据 → 转成 LeRobot 用于训练和共享 → 需要跨本体预训练时再转 RLDS‌。这样三套生态都能吃到，不被任何单一格式锁死。

2. 机器人本体运行时层（边缘/实时记录）

SQLite‌：ROS 2 的 rosbag2 默认存储后端，每个 bag 文件本质是一个 .db3 的 SQLite 库，支持随机访问和事务完整性，是机器人"黑匣子"的默认选择。

MCAP‌：ROS 2 社区新推的记录格式，日志场景比 SQLite 更适合实时写入。

时序数据库‌：用于高频传感器（IMU、力/力矩、关节角度）数据。主流选择有 ‌TDengine‌、‌Apache IoTDB‌、‌InfluxDB‌、‌TimescaleDB‌。其中 IoTDB 的 TsFile 格式从端侧到云端统一，资源受限的车载/边缘网关是它的主场。

3. 元数据与业务层（关系型数据库）

机器人台账、任务记录、数据集版本管理、标注任务追踪这类‌结构化业务数据‌，还是用关系库：

PostgreSQL‌（尤其 TimescaleDB 是 PG 的时序扩展，能"一鱼两吃"）

MySQL / MariaDB

4. 海量多模态数据湖层

机器人集群每天可产生‌数十到上百 TB‌ 数据（视频、点云、深度图、IMU、触觉），年度到 PB/EB 级。这层用‌对象存储‌：Ceph、MinIO、以及专门的 AI 数据平台（如杉岩 AIDP），单桶承载千亿对象。

二、那"选哪个好"？

目标 推荐组合

入门学习/跑通VLA训练‌ LeRobot 格式 + Parquet/MP4，直接用 HF 上现成数据集

复现经典论文/跨本体预训练‌ RLDS（OXE 生态）

自己采集原始数据‌ HDF5 或 Zarr 作源，MCAP 做实时日志

传感器高频流‌ IoTDB 或 TDengine（国产、边缘友好）

业务元数据/台账‌ PostgreSQL（顺手还能用 TimescaleDB 做时序）

PB级多模态数据湖‌ 对象存储（Ceph/MinIO）+ 分层冷温存

三个最关键的：‌

LeRobot（Parquet+MP4）‌——训练和共享的首选，生态最活跃；

HDF5/Zarr‌——原始采集的可靠源格式，随机访问强；

SQLite（rosbag2）+ 时序库（IoTDB/TDengine）‌——机器人本体运行时的记录标配。

三、两个提醒

别用传统关系库硬扛高频时序数据‌。关系库为事务均衡设计，面对只增不改的高频追加会出现写入积压、查询超时，这是架构不匹配的问题。

具身数据目前最大痛点不是"存不下"，而是"缺高质量数据"和"格式不统一"‌。行业正面临供需差约两个数量级（有效存量百万小时 vs 需求亿小时），真机数据成本 500–1000 元/小时。所以选型时‌格式是否兼容开源生态‌（LeRobot、OXE）比参数表上的数字重要得多——不然采出来的数据每个环节都要写转换脚本，还可能丢时序信息。

针对具体场景（数据采集端‌、‌模型训练端‌、还是‌机器人本体部署端‌）出一份更细的选型对照表