Query the whole fleet in one SQL statement
No more copying ten bags to a workstation and waiting on a Python script. Every robot's history is already columnar and queryable, so a fleet-wide question returns in seconds, not in 40 minutes.
Event data infrastructure
A replayable
A replayable
event data layer
for when history
matters.
Continuum keeps a complete, ordered, correctable history of everything your systems produce - robot fleets, sensor streams, market data - and lets you replay any of it into new models, simulations, and analytics. One backbone to stream, store, query, replay, and correct large event data. Proven in production.
continuum.sdk.ts
// Append a 12 MB sensor frame as one event
await continuum.append({
topic: "robot-fleet-eu-7",
payload: frame, // 12 MB Arrow batch
ordering_key: "robot-243",
})
// Replay from any historical position
for await (event of continuum.replay({
topic: "robot-fleet-eu-7",
from: "2026-04-29T00:00:00Z",
})) { /* re-train */ }
// Correct yesterday's labels, propagate downstream
await continuum.correct({
from_position: 409_812_005,
payload: corrections,
})
Production metrics
- 3+ yrs
- in production
- 50+
- production networks
- 2B+
- events / month
- 11.9PB
- logical data retained
- 1.3GB/s
- sustained throughput
What is Continuum
Point your data at it.
Point your data at it.
Replay any of it, anytime.
Continuum is a replayable event data layer. Your producers write events to it - large payloads included - and it keeps one complete, strictly ordered history you can replay, query, and correct.
- Re-label a week of sensor data once and every downstream model retrains on the corrected history
- Replay last Tuesday's run into a new policy
- Query the whole fleet in SQL with no ETL
- Stream Ingest events over any protocol
- Store Columnar Parquet on S3, retained long-term
- Query SQL-ready on the write path, no ETL
- Replay Re-run history from any point in time
- Correct Fix the past and propagate downstream
Continuum is one system of record for large, changing event data, in place of the broker-plus-lake-plus-replay-jobs stack teams build by hand.
Why streaming breaks at scale
Event streaming was
Event streaming was
built to move data - not to keep it.
Every system can move events. Almost none can keep history ordered, queryable, replayable, and correctable at the same time. These are the five gaps that show up at scale - and the five primitives Continuum was built around to close them.
| Primitive | The Gap | Continuum |
|---|---|---|
OrderingEvents land in arrival order, not event-time order - so history is wrong from the very start, and every replay inherits the error. |
Strict event-time orderingA single globally ordered stream per topic places every event where it actually happened - concurrent writers, no partition ceiling. |
|
CorrectionAppend-only logs can't fix the past. When history changes, every downstream system silently diverges until someone reconciles it by hand. |
Correction as a storage primitiveOne call rolls back affected history, invalidates the impacted data, and propagates the fix to every consumer - no per-team reconciliation. |
|
ReplayReplay requires fragile, expensive custom jobs rebuilt per incident. It's never a first-class operation. |
Replay from any pointRe-run any historical sequence against a new model, policy, or fixed input - native and first-class, no custom pipelines. |
|
PayloadsLarge payloads hit broker limits, so semantic units get split into claim-checks and lose their meaning downstream. |
Large payloads, intact1 MB to 100 MB+ payloads are first-class units. Decoded blocks, sensor frames, and robotics episodes stay whole. |
|
QueryQuerying means ETL into a separate warehouse - another copy, another pipeline, another version of the truth. |
Query-ready on the write pathArrow in memory flushes to columnar Parquet on S3 with Iceberg-compatible access. Data lands useful - no ETL needed. |
How it works
One backbone.
One backbone.
Any protocol in, any protocol out.
Whatever protocol or schema you ingest, Continuum converts it server-side to Apache Arrow and persists it as columnar Parquet on S3. Data written via any protocol is immediately readable through all the others - and it slides under the stack you already run.
Any protocol in
- Kafka
- AMQP / RabbitMQ
- Amazon SQS
- REST
- Arrow Flight
Any schema
Protobuf · Avro · Apache Arrow · JSON
Server-side conversion
Apache Arrow
Stored as
Parquet + ZSTDS3-native · Columnar compression
Operational primitives
Memory · Replay · CorrectionOrdering · Large payload · Queryable
Any protocol out
- Kafka consumers
- AMQP / RabbitMQ
- Amazon SQS
- REST / HTTP
- Arrow Flight (gRPC)
Any query engine
ClickHouse · DuckDB · Spark · Snowflake · BigQuery · Pandas · dbt
Published once, readable everywhere. Continuum speaks Kafka to your producers, Iceberg to your lakehouse, Arrow Flight to your realtime apps, and Parquet to your S3 bucket, so you can adopt it for one topic or one workload without migrating the rest of your stack. Your data stays in open formats in your own bucket - no proprietary lock-in.
For physical AI teams
Built for physical AI.
Physical AI teams - robot fleets, drone programs, autonomous vehicles, and the humanoid and AV foundation-model labs behind them - run a data loop on large multimodal data whose ground truth keeps changing. It's the exact workload shape Continuum was hardened on years earlier: large payloads, strict ordering, corrected history, replay at scale.
Your pipeline today
- Record MCAP / ROS 2 bags on every robot
- Copy bags to S3
- Run conversion scripts to Parquet
- Train - then rebuild datasets when labels or calibration change
Cross-fleet questions mean downloading bags and waiting on a Python script. Corrections mean rebuilding from scratch.
Your pipeline with Continuum
- Record straight into Continuum (MCAP-compatible)
- Data lands ordered, queryable, and replayable - no conversion step
- Query the whole fleet in SQL; replay any episode into a model
- Re-label or recalibrate once - corrections propagate through history
Keep Foxglove as your frontend and your trainer as-is. Continuum sits underneath as the history layer.
Replay episodes into models & simulators
Feed exact historical runs into new policies, models, and evaluation pipelines. Close the eval loop on what actually happened, not what someone remembered to capture.
Reproduce incidents frame by frame
Query the full event sequence behind a failure weeks later - without stitching logs together - to root-cause faster and ship safer models sooner.
Retrain on corrected history
Apply updated labels, calibrations, and ground truth in the order they actually happened. Corrections propagate through history - no dataset rebuilds.
One source for live agents & training
Serve production and training jobs from the same event backbone. No parallel pipelines, no production-versus-training drift.
Generate grounded synthetic data
Perturb real-world runs and replay them through models to create synthetic training data grounded in real episodes. MCAP import and export supported.
Where Continuum fits
One substrate. Many domains.
The same primitives serve any domain where event data is large, sequence-sensitive, and prone to change. Physical AI is where we start - not where we stop.
Primary focus
Physical AI & robotics
Robotics data infrastructure for robot fleets, drones, and autonomous vehicles: episode replay, sensor recalibration, fleet-wide retraining, and incident reproduction - all from one ordered, correctable history.
Explore Physical AIProduction-proven
Blockchain & onchain data
Where Continuum was hardened: decoded, normalized, reorg-aware data across 50+ chains, drop-in Kafka-compatible.
Explore BlockchainContinuum for agents
Agentic AI
Agentic AI infrastructure for AI agents: replay multi-step agent trajectories against new models and policies, serving traces back as live input to the eval loop, not just dashboards.
Explore Agentic AIExpansion vectors. The same correction-aware, replayable history maps directly onto financial markets (settlement reversals, regulatory replay), defense and intelligence (mission replay, sensor fusion), and health tech (correction-heavy patient timelines).
Why now
The category is being created - and the position is open.
Four things are true at the same time, and that combination has a short window.
01 - The cost
Teams already pay for not having this
Every organization running large event data on a fragmented stack pays for it today - in engineering headcount, compute, custom reconciliation, replay pipelines rebuilt per incident, and models retrained against history that turned out to be wrong.
02 - The window
Physical AI infrastructure decisions are happening now
Well-funded physical AI teams are in active greenfield buildout and haven't committed to a data backbone. Once a training pipeline hardens around a storage layer, re-platforming is a multi-year project. The buying decision happens first.
03 - The movement
The Kafka re-platforming wave is in motion
Engineering teams are actively moving from broker-disk Kafka to S3-native architectures - driven by storage cost, rebalancing overhead, and partition ceilings. Even the team that invented Kafka is replacing it after hitting hard limits.
04 - The signal
The category is being priced
IBM's ~$11B acquisition of Confluent confirms real-time data infrastructure as a core enterprise-AI asset, and validates the S3-native direction. None of the existing players solve large payloads, native correction, global event-time ordering, and replay as primitives together.
Proven in production
Not a prototype. Production infrastructure.
Continuum was hardened in one of the harshest event-data environments anywhere - blockchain - before opening to other industries.
- 3+ yrsIn Moralis production
- 50+Blockchain networks served
- 11.9 PBLogical data retained
- ~17×Compression (≈700 TB on S3)
- 2B+Events per month
- 1.3 GB/sSustained throughput (load test)
- 186KRows/sec on 11.5 CPU cores
- ZeroBroker rebalancing, ever
Proven, not promised. Continuum isn't a prototype or a roadmap. It's infrastructure that has run in one of the most demanding production environments for years - so you're adopting something already battle-tested, not betting on what it might become.
Early signal
What design partners are telling us.
Anonymized while programs are early - spanning physical AI, applied research, and financial data.
This is perfect — it solves the exact problem we have with replaying real-world robot data as we build out our tech stack.
// Physical AI lab, factory robotics
We've been looking for months for a solution for continuous, replayable data.
// Applied AI research lab
This is probably the best thing I've seen so far, and I've been digging around this space for the better part of a year.
// Blockchain data infrastructure team
I like that I can handle the data the way I want. As long as I have all of it, and it's pre-processed, even better.
// Institutional digital-assets platform
The pattern
The biggest infrastructure companies started inside one company.
Category-defining infrastructure is rarely invented to be sold. It's built out of necessity, run in production, and only then recognized as a category. Continuum follows the same path.
-
Amazon's internal cloud infrastructure, built to serve amazon.com
→ The cloud category -
Built at LinkedIn to handle real-time activity stream data
→ Real-time data infrastructure -
Built at Berkeley's AMPLab for large-scale data processing
→ The data lakehouse
-
Google's internal cluster scheduler, open-sourced in 2014
→ Container orchestration
- Continuum Built inside Moralis to solve blockchain event data at production scale → Event data infrastructure
How it compares
Not a cheaper Kafka. A different layer for event history.
Continuum is the only system where strict event-time ordering, large payloads, native correction, query-ready storage, and replay are all first-class at once.
| Capability | Kafka & brokers | S3-native Kafka | Lakehouse / analytics | Robotics tooling | Continuum |
|---|---|---|---|---|---|
| Strict event-time ordering | per-partition | per-partition | after the fact | not the backbone | built-in |
| Large payloads native | 1 MB cap | inherits cap | n/a | file-based | 100 MB+ |
| Native correction handling | append-only | append-only | re-run ETL | manual | storage primitive |
| Query-ready on write | ETL required | log on S3 · ETL | is the warehouse | visualization only | columnar Parquet |
| Replay from any point | retention only | retention only | no | per-file | first-class |
Economics at scale
Keep all your history. Without the storage bill exploding.
For physical AI, the real cost pain is retention - holding petabytes of episode and sensor history long enough to replay and retrain on it. Continuum's diskless, S3-native, columnar design makes infinite retention economically trivial. Replay is only useful if you can afford to keep the data, and here you can.
40-60%
lower infrastructure cost than Kafka alternatives at production scale
Lower because the architecture is different, not because we discount. There are no brokers to over-provision, no replication factor multiplying your disk, and no rebalancing tax - just columnar Parquet on object storage you already pay for.
Enterprise-ready
Request demo
Built for the strictest controls.
The same infrastructure that handles chain reorganizations and sustained high throughput around the clock, with the controls enterprise teams require.
-
Enterprise Security
S3 encryption at rest. TLS in transit. Per-customer data isolation. SOC 2 compliant infrastructure.
-
Self-Hosted Option
Run Continuum on your infrastructure, your cloud, your terms. No control plane dependency. Full data sovereignty.
-
Enterprise Support
Dedicated support engineers. SLA guarantees. Architecture reviews and migration planning included.
-
Battle-Tested Reliability
Handles reorganizations, forks, and sustained high throughput - 24/7, with zero broker rebalancing.
FAQ
Frequently asked questions
The short version of what Continuum is, who it's for, and how it fits with what you already run.
What is Continuum?
Continuum is event data infrastructure - one system that ingests events from any source, gives every event a strict place in a global timeline, and serves that history back replayable, correctable, and query-ready, without copying it into a separate warehouse. It's the system of record for large, changing event data.
Is Continuum a Kafka alternative?
Continuum speaks the Kafka wire protocol, so existing Kafka clients work unchanged - but it's a different layer. Where Kafka moves small messages on an append-only log, Continuum keeps large event history ordered, correctable, replayable, and queryable on S3-native columnar storage. It's not a cheaper Kafka; it's the event-history substrate Kafka was never built to be.
What is event data infrastructure?
Event data infrastructure is the system of record for large, changing event data. It captures events in strict order, retains them long-term, and makes the full history replayable, correctable, and queryable from a single backbone - rather than a stitched-together stack of streaming broker, data lake, replay jobs, and reconciliation logic.
Can Continuum handle large sensor payloads?
Yes. Continuum treats 1 MB to 100 MB+ payloads as first-class units. Decoded blocks, sensor frames, multi-camera demos, and robotics episodes stay intact as complete semantic units, with no claim-check workarounds or downstream reassembly.
How does correction work?
Correction is a storage primitive in Continuum. One call rolls back affected history, invalidates the impacted data, and propagates the fix to every downstream consumer consistently - so you don't maintain bespoke reconciliation logic per team or rebuild datasets when ground truth changes.
How is Continuum different from an event store or event-sourcing database?
Event-sourcing databases such as EventStoreDB handle application state at single-stream scale. Continuum is built for high-throughput, correction-aware production workloads: large payloads, strict event-time ordering across the whole topic, query-ready columnar storage, and replay as a first-class operation. It is the event store for large, changing event data at production scale, not a model of a single application's state.
Do I have to migrate off my existing stack?
No. Continuum speaks Kafka to your producers, Iceberg to your lakehouse, Arrow Flight to your realtime apps, and Parquet to your S3 bucket, so it slides under the stack you already run. You can adopt it for a single topic or workload and leave the rest of your pipeline untouched.
Does Continuum run on the robot?
No - Continuum is off-board infrastructure, not your on-robot control loop. It's the history layer that sits behind the fleet: recording, querying, replaying, and correcting episodes for debugging, retraining, and audit. Your sub-millisecond on-device perception and control stay exactly where they are.
Is Continuum production-proven?
Yes. Continuum has run in Moralis production for 3+ years across 50+ blockchain networks, retaining 11.9 PB of logical data (roughly 17× compression) and processing 2B+ events per month at sustained multi-gigabyte-per-second throughput, with zero broker rebalancing.
Connect
Got a workload where
Got a workload where
history matters?
If you're hitting a payload ceiling, hand-rolling reconciliation on append-only streams, or stitching a stack together to make replay possible - we'd like to hear what you're building.
