Keyed current state
Latest row per instrument, maintained from the trade feed.
Collapse the tick store, the keyed state cache and the stream fan-out into one engine with deterministic ordering.
The problem
A trading platform is a chain of systems held together by reconciliation jobs: a tick store, a cache for live state, a stream processor for signals and a warehouse for research. Every boundary adds delay, and every copy is a source of disagreement.
The boundary that decides outcomes is the one where a strategy reads state a fill just changed, and that is exactly the boundary a multi-system stack cannot make consistent.
One engine that keeps every trade durable, derives keyed state from it continuously and serves both live removes the reconciliation problem instead of automating it.
Where NYXDB fits
Architecture
Ticks land in one durable table and every committed write is published once, to the transformations that keep per-instrument state and to every STREAM SELECT consumer, so history, current state and derived signals share one runtime.
Every tick, in an append-only table, in the write-ahead log before acknowledgement.
The latest row per instrument, kept current by transformations in an UPSERT table.
Sums, minimums, maximums and weighted averages such as VWAP, maintained as grouped folds.
Every accepted version is kept, so research can reread a table exactly as it was at any commit, with AS OF COMMIT.
In practice
The examples use the same two tables on every page. See the SQL reference for full syntax.
SELECT address, token, amount, updated_atFROM balancesWHERE chain_id = 1 AND address = '0x9c2e4f1a';Capabilities
Latest row per instrument, maintained from the trade feed.
Late and shuffled writes converge to the same state, with VALID BY and REVISION BY.
One table serves the live feed and research reads.
Retire the cache and the stream processor.
Learn more
Explore the market-data solution or run a node.