Sharded ingest
One owner per shard serializes its commits.
Back homeIndustry
Industrial IoT
Durable, ordered device history, the current state of every machine and live follows, in one engine for the plant’s telemetry.
The problem
Where the usual stack breaks
- 01
Industrial telemetry is unforgiving: sensor and control streams are high-volume and bursty, ordering matters, and a dropped reading can mean a missed fault.
- 02
Cloud-only pipelines add delay and a failure mode when connectivity drops; warehouse-only pipelines answer current-state questions with full-history scans.
- 03
You want an engine that keeps ordered history durably, keeps one current row per machine, and lets operators follow a machine’s readings as they commit.
Where NYXDB fits
Use-case journeys
Architecture
How NYXDB fits industrial IoT
Readings land in tables sharded by machine, each shard with one owner that serializes its commits; keyed tables keep the latest state per machine; STREAM SELECT follows a single machine live.
- 01
Ingest
Every reading is in the write-ahead log before it is acknowledged.
- 02
Ordered
Versions are ordered by the coordinates you declare, not by arrival, with VALID BY and REVISION BY.
- 03
Current state
The latest row per (machine, metric), in an UPSERT table.
- 04
Deploy
A container image and a Kubernetes manifest ship with the engine.
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
Durable before ack
Write-ahead log persistence precedes acknowledgement.
Keyed current state
Latest row per machine.
Simple deployment
A container image or a Kubernetes manifest.
Learn more