Nexma DataBase
Every object's position, through time
Nexma DataBase is a purpose-built spatial-temporal database that stores the position of every object across time, at planetary scale. Unlike a conventional store that keeps only the latest coordinate, it retains a continuous, queryable history — so you can ask not just where an asset is now, but where it was at any moment in the past.
Conventional databases were built to answer where things are now. The moment a position updates, the previous one is gone, and storing the full history naively becomes unaffordable at scale. The DataBase is engineered for the opposite: every position is retained, compressed into a compact delta-log, and indexed so history is always available and always fast.
Core concepts
- Spatial-temporal core. Every record is indexed in both space and time. Query a single object's full track, or the state of an entire region at any instant — past or present.
- Delta-log encoding. Movement is stored as compact deltas rather than full duplicated rows, holding billions of position updates without runaway storage cost.
- Time-travel query. Scrub to any moment and read the exact spatial state then, without restoring a separate backup.
- Planetary ingest. Built to absorb millions of telemetry updates per second, fed by the Event Broker and written straight into the time-aware backbone.
The DataBase is the time-aware backbone for high-frequency position history. The Nexma DataStore is the versioned filesystem that holds your world model. They are complementary, not interchangeable.
How it works
The DataBase pairs a compact temporal core with spatial indexing. Telemetry streams in through the Event Broker, lands as deltas, and becomes queryable across time the moment it arrives.
1Event Broker --(positions, readings)--> Nexma DataBase
2 |
3 +--------------------+--------------------+
4 v v v
5 live tracking time-travel reads region state
6 (present moment) (any past instant) (what was where)The same engine drives the live map and the permanent historical record, so there is no separate analytics pipeline to keep in sync.
Every position in 34 bytes
The efficiency that makes planetary history affordable comes from the delta-log. Instead of writing a full row for every update — coordinates, identifiers, metadata, timestamps duplicated each time — the DataBase records only what changed since the last position, encoded as a compact delta.
In practice that lands on the order of tens of bytes per update — about 34 bytes for a typical position — versus the hundreds a row-per-update store consumes.
| Approach | Per update | One million objects, 1 Hz, 1 year |
|---|---|---|
| Row-per-update store | Hundreds of bytes | Tens of terabytes, often downsampled |
| Delta-log encoding | ~34 bytes | A fraction of that, full fidelity kept |
The practical effect is that you keep complete history instead of downsampling. Investigations, audits, and after-action reviews always have ground truth to work from, not a guess.
Time-travel queries
Because every position is retained and indexed by time, the DataBase answers questions a "latest coordinate" store cannot:
- Full position history — every update to an object's location is a delta, giving a continuous, replayable track for its entire lifetime.
- Point-in-time reads — reconstruct the exact spatial state of any object or region at any past instant.
- Track and region queries — pull a single object's path, or the state of an entire bounding region at a moment, returning typed features.
- Interactive replay — scrub a timeline to animate movement and change across the whole dataset at responsive speed.
Spatial-temporal indexing keeps these queries interactive rather than full table scans, so replay and historical analysis feel as fast as the live map. Jax reads the DataBase through the same generic primitives it uses everywhere, with every read scoped and logged.
How it complements the DataStore
The two stores answer different questions, and most projects use both.
| Nexma DataStore | Nexma DataBase | |
|---|---|---|
| Holds | The world model — entities, links, geometry, constraints | Position history of moving objects |
| Optimized for | Versioned, branchable design and authoring | High-frequency writes and time-travel reads |
| Question | "What is the world, and how is it structured?" | "Where has everything been, and when?" |
| Cadence | Edited deliberately, versioned | Streamed continuously |
The DataStore holds the world model the DataBase tracks through time. An object defined and typed in the DataStore accumulates its movement in the DataBase; together they give you both the structured present and the full motion history.
Where it fits
The DataBase sits behind the Event Broker, which streams telemetry into it, and beneath GeoEngine, which analyzes across its history. It powers live tracking on the Globe and the permanent record behind it from one engine.
Where to go next
- Nexma Event Broker — the telemetry stream that feeds the DataBase.
- Nexma DataStore — the world model the DataBase tracks through time.
- Live data and the Globe — live tracking and the temporal slider.
- GeoEngine — spatial analysis across position history.