Durable telemetry
Writes persisted before acknowledgement.
Back homeIndustry
Logistics & mobility
Fleet telemetry, live vehicle state that survives late and re-sent updates, and live reads on the dispatch path.
The problem
Where the usual stack breaks
- 01
A logistics or mobility platform tracks a fleet in motion: a stream of telemetry, current vehicle state that dispatch reads constantly, and updates that arrive late or twice when a vehicle reconnects. The usual stack is a telemetry pipeline, a cache for live state and a separate service per question.
- 02
The split adds delay to exactly the reads that need to be prompt, opens a gap between what a vehicle reported and what the dispatcher sees, and lets a late update overwrite a newer one.
- 03
You want durable telemetry ingest, vehicle state ordered by the vehicle’s own sequence rather than by arrival, and live reads in the same SQL.
Where NYXDB fits
Use-case journeys
Architecture
How NYXDB fits logistics & mobility
Telemetry lands in one table; vehicle state lives in a versioned table ordered by the vehicle’s own sequence, so a late update never wins over a newer one; STREAM SELECT pushes each state change to dispatch.
- 01
Ingest telemetry
Every telemetry row is durable before it is acknowledged.
- 02
Current state
The winner per vehicle is picked by sequence, in a VERSIONED table with VALID BY and REVISION BY.
- 03
History
Every accepted version is kept beside the current winner.
- 04
Dispatch
Vehicle-state changes reach dispatch live, with STREAM SELECT.
In practice
Representative statement
The examples use the same two tables on every page. See the SQL reference for full syntax.
Balances, as a versioned table with a slice per producer
CREATE TABLE balances ( chain_id UINT16 NOT NULL, address STRING NOT NULL, token STRING NOT NULL, amount UINT256 NULL, updated_at DATETIME64(3, 'UTC') NULL, balance_index UINT128 NULL, balance_version UINT64 NULL, transfer_count UINT64 NULL, last_transfer_at DATETIME64(3, 'UTC') NULL, activity_index UINT128 NULL, PRIMARY KEY (chain_id, address, token), ATTRIBUTE GROUP holding (amount, updated_at, balance_index, balance_version) VALID BY (balance_index) REVISION BY (balance_version), ATTRIBUTE GROUP activity (transfer_count, last_transfer_at, activity_index) VALID BY (activity_index))MODE VERSIONEDSHARD BY (address) SHARDS AUTOORDER BY (chain_id, address, token);Capabilities
What you get out of the box
Late-update safe
A late update never overrides a newer one, with VALID BY and REVISION BY.
Keyed vehicle state
Current row per vehicle, history retained.
Simple deployment
A container image or a Kubernetes manifest.
Learn more