Durable ingest
Writes persisted before acknowledgement.
Back homeIndustry
Robotics & drones
High-rate sensor and pose streams, the current state of every unit and live follows, on one engine.
The problem
Where the usual stack breaks
- 01
A robot or drone fleet emits high-rate sensor and pose telemetry continuously, and operations needs the live state and health of every unit right now, including units whose updates arrive late after a link drop.
- 02
The usual stack splits pose streams into a processor, current state into a cache and history into a warehouse: three systems that drift, and a fleet view that lags the units it tracks.
- 03
You want one engine that stores pose and sensor streams durably, keeps per-unit state ordered by the unit’s own sequence, and lets operators follow one unit live.
Where NYXDB fits
Use-case journeys
Architecture
How NYXDB fits a robot fleet
Pose and sensor events land in one durable table; keyed versioned tables hold the latest state per unit, ordered by the coordinates you declare; STREAM SELECT follows a single unit or the whole fleet.
- 01
Ingest
Every pose and sensor event is durable before it is acknowledged.
- 02
Fleet state
The latest state per unit, in a VERSIONED table where a late update never overrides a newer one.
- 03
History
Every accepted version is kept beside the current winner.
- 04
Live streams
Pose and health changes reach fleet dashboards as they commit, with STREAM SELECT.
In practice
Representative query
The examples use the same two tables on every page. See the SQL reference for full syntax.
Live volume per token, as a query that stays open
STREAM SELECT chain_id, token, SUM(amount) AS volume, COUNT(*) AS transfersFROM transfersGROUP BY chain_id, token;Capabilities
What you get out of the box
Arrival-order independent
Updates are ordered by sequence, not arrival, with VALID BY and REVISION BY.
Keyed fleet state
Latest row per unit, history retained.
Simple deployment
A container image or a Kubernetes manifest.
Learn more