Mosaico is an open source data platform from Mosaico Labs built for robots and physical AI, and it gathers scattered sensor logs into one data asset that can be queried and trained on.

The hardest part of robot data comes after collection. A self driving rig makes one run, the lidar sweeps at 10 hertz, the IMU records at 100 hertz, the camera shoots at 30 hertz, and the clocks of the three sensors are still drifting apart. On disk this usually lands as a recording bag starting at a few hundred gigabytes, and pulling one signal from one second of it means unpacking the whole bag first. By the time it goes into a model there is another pile of one off scripts to write, aligning asynchronous, sparse data into fixed rate tensors.

Mosaico treats that as infrastructure. It is built by Mosaico Labs, open sourced on GitHub in December 2025 under the Apache-2.0 licence. The three co-founders spent more than a decade on autonomous driving systems between Palma and Silicon Valley, working with petabyte scale, high frequency sensor data for years; by their account, those brittle, hard to debug, nearly unauditable hand built pipelines are what prompted the rebuild.

Two components: a Rust daemon and a Python SDK

The whole platform is two pieces. The server is a daemon called mosaicod, written in Rust, responsible for storage, catalogue management, writing data and retrieval; the client is a Python SDK that developers import into their own scripts to upload and query. Between them sits a standard client and server model, and data moving either way needs no extra serialisation and no format conversion.

The retrieval path deserves a sentence of its own. The usual approach treats data as an array of bytes, so reading one signal means parsing the whole file from the start. Mosaico borrows from the modern data lake playbook and uses a zero copy architecture to reach a given signal at random, stepping past the limits of the bag format itself; streams are indexed as they are written, the query engine uses the index to cut away what is irrelevant, and only the stretch that is needed comes out.

Write, query, replay: three primitives

The SDK interface is deliberately thin, summed up by the vendor as three actions, push, find and stream, standing for writing, querying and replay. Writing means creating a sequence first, then a topic inside it, then pushing timestamped messages one by one; a topic binds its body type at creation, an IMU for instance. The session layer and the topic layer each carry their own failure policy, either deleting cleanly or keeping partial data for recovery.

Queries are built by chaining, with no SQL to write and no second query language to learn. You can match on sequence name, or filter on business metadata, for example combining project name equals some value with visibility below 50, and the server completes the multi domain filter in a single request. Every match comes back with exact start and end timestamps at nanosecond precision.

A typed body, so the data speaks in physical quantities

What lets queries be this short is a strictly typed data body laid over the data. A message is not treated as a run of bytes but has to be known for what it means. The vendor ships models for common robot data such as IMU, GPS, images and pressure, and a developer can extend the set with a model of their own in a few lines of Python.

The immediate gain is that a query can be written in physical quantities. Describe an acceleration condition and it reads as a test on the x axis value of acceleration, and the same condition serves both filtering and aggregation. The vendor also offers filters that cluster matches within a time window and that intersect across topics, which answer when something happened rather than merely which topic matched.

An immutable data layer and data lineage

Another trade off sits in version management. The common move is to put a version number on the data, but versions make it vague which copy a given query saw. Mosaico uses an immutable data layer instead: new data is appended sideways, older layers are never rewritten, so the query history stays deterministic and reproducible, and every transformation from raw sensor to training set can be traced. For anyone who has to reconstruct a failure afterwards, or certify a result, that matters more than performance.

Aligning sensor streams into training batches

The machine learning module built into the platform covers the road from raw recording to training data. It takes sensor data that is not synchronised and splits the work into three stages: extraction handles input, output and memory, synchronisation handles time alignment, and windowing handles the batch shape, and the three can be adjusted or replaced independently. A developer sets the sampling step and the resulting batch goes straight into fine tuning, with no need to build a large intermediate file locally, and a dataset can be streamed out of the platform rather than downloaded whole.

Ingest, deployment and where it runs

On the ingest side it natively supports common robot data formats such as ROS, ROS 2 and MCAP, stays decoupled from the middleware, and lets the compression ratio follow the format. Beyond those, the platform covers six stages: the data body, multimodal retrieval, data lineage, orchestration, certifiability and data containers.

For deployment, mosaicod ships prebuilt binaries and container images, with version tags in four classes, stable, minor, exact and nightly, and production is best pinned to an exact version. Storage supports S3 compatible object storage by default and can also fall back to the local file system, while metadata relies on a PostgreSQL instance. The daemon currently supports only Linux and macOS, so Windows users run it inside WSL2.

Open source and commercial tracks

Mosaico is open source under Apache-2.0, with the core engine, the middleware independence and the ROS compatibility all inside the open scope, and the vendor has written on its home page that it will not put a paywall in front of that foundation layer. The other track is a commercial licence for enterprise settings, offering an audit panel, fine grained access control, user management, and custom databases and connectors. That said, although the project is open, legal constraints mean it does not currently accept merge requests from the public, and anyone who wants to take part has to contact the team first and become a recognised contributor.

From recording bag to data asset, what Mosaico deals with is a very concrete problem: letting robot teams stop assembling their own data pipeline, and handing storage, retrieval and the preparation of training data to one shared foundation.