Back homeIndustry

Exchanges & market infrastructure

Order-book state, matching-engine telemetry and surveillance queries on one engine, with every trade and the state derived from it in one place.

The problem

Where the usual stack breaks

01
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 what the market looked like at a given point.
02
Splitting that across a tick store, a 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.
03
You want one engine that stores fills and deltas durably, keeps per-instrument book and gateway state, and answers surveillance queries over the same history in the same SQL.

Where NYXDB fits

Use-case journeys

Order-book & tick store

Keep every trade durable and the state derived from it current.

Market data & trading analytics

Matching-engine telemetry

Engine and gateway metrics become live operational relations, maintained by materialized views.

Real-time dashboards

Surveillance & risk

Per-participant folds and point-in-time reads for market-abuse and risk checks.

Fraud & risk

Architecture

How NYXDB fits market infrastructure

Fills and book deltas land in one durable table; keyed tables hold the latest state per instrument and gateway; transformations and grouped STREAM SELECT maintain the aggregates that operations and surveillance read.

01
Ingest
Fills land in tables sharded by instrument; one owner per shard serializes its commits.
02
Book & gateway state
The latest row per (instrument, level) and per gateway, in UPSERT tables.
03
Surveillance
Grouped scans over durable history, and the market state at any past commit with AS OF COMMIT.
04
Live streams
Per-instrument totals reach operations dashboards as fills commit, from a grouped STREAM SELECT.

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 transfers
FROM transfers
GROUP BY chain_id, token;

Capabilities

What you get out of the box

Sharded ingest

One owner per shard serializes its commits.

Keyed book state

Latest row per instrument and gateway.

Point-in-time reads

Reread any past market state, with AS OF COMMIT.

Live push

Changes reach operations dashboards as they commit, with STREAM SELECT.

Learn more

Tables

Current state per instrument.

Versioned tables

History and AS OF COMMIT.

Streaming

Grouped queries that stay open.

One engine for the trading venue

Explore market data & trading analytics or run a node.

Get startedRead the docs