Exchanges & market infrastructure
Order-book state, matching-engine telemetry, and surveillance queries on one engine — the freshest write served as the fastest read.
The problem
Why this is hard today
An exchange runs three clocks at once: the matching engine emits fills and book deltas continuously, operations needs the state of every book and gateway right now, and compliance needs to reconstruct exactly what the market looked like at any instant.
Splitting that across a tick store, an in-memory cache for book state, and a warehouse for surveillance means three schemas and a reconciliation layer that itself becomes a failure source — with an audit trail that can disagree with the cache.
The fit is one engine that ingests fills and deltas at line rate, keeps per-instrument book and gateway state as O(1) reads, and answers surveillance queries over durable history in the same SQL.
Where NYXDB fits
Use-case journeys
Order-book & tick store
Serve the freshest fill as the fastest read; keep the full tick history durable underneath.
Market data & trading analyticsMatching-engine telemetry
Continuous transforms turn engine and gateway metrics into live operational tables.
Real-time dashboardsSurveillance & risk
Exact counts and read-your-writes state for real-time market-abuse and risk checks.
Fraud & riskArchitecture
How NYXDB fits market infrastructure
Fills and book deltas append durably at line rate under the memory governor; keyed tables hold the latest state per instrument and gateway; continuous transforms maintain the aggregates surveillance and operations read as ordinary tables.
- 01
Line-rate ingest
Shard-owned, lock-free write paths, WAL-backed, governed under pressure.
- 02
Book & gateway state
Keyed tables keep the latest per (instrument, level) and per gateway — O(1) reads.
- 03
Surveillance
Columnar scans and exact counts over durable history in the same engine.
- 04
Live streams
STREAM SELECT pushes book and telemetry deltas to ops dashboards as they commit.
Real SQL
Representative queries
SELECT instrument, best_bid, best_askFROM book_stateWHERE best_bid >= best_ask;Every statement follows the engine’s own test SQL shapes. See the SQL reference for full syntax.
Capabilities
What you get
Line-rate ingest
Lock-free shard-owned write paths.
O(1) book state
Latest per instrument and gateway, instantly.
Exact surveillance
Deterministic counts over durable history.
Live push
STREAM SELECT to operations dashboards.
Proof
Measured on the vetted benchmark lane
order-book point consult on warm postings
sharded ~1µs
vetted table
View benchmark1.53M rows/sdurable fill/tick ingest, single core
1M-row batches, best durable mode
vetted table
View benchmark268nskeyed book-state count(), flat 1k–16k keys
O(1) maintained counter
vetted table
View benchmarkMeasured on AMD EPYC 9554P 64-Core Processor (64t), 1505GB RAM, 6x NVMe — measured on server-class hardware. Release build, median of 5 (re-captured stragglers: median of 3), commit-pinned (7945ae33, 2026-07-09). Ingest figures are engine-side. See the full benchmark suite.
One engine for the trading venue
Explore market data & trading analytics or run a node.