DB
HTAP engine · streaming + historical in one runtime

The database where the freshest write is the fastest read.

NYXDB is a distributed, high-throughput engine for large-scale blockchain and analytics workloads. Streaming SQL, keyed tables with exact counts, and read-your-writes freshness — collapsing the cache, the queue, and the stream processor into one deterministic runtime.

$ docker run -p 8123:8123 nyxdb/nyxdb:latest

nyxdb — trading.sql
nyx>
859
native functions
built in
154 MB
container image
deploy anywhere
O(1)
keyed counts
always exact
HTAP
OLAP · OLTP · stream
one engine
Streaming SQL

Continuous transforms that live inside the database.

Define standing pipelines with CREATE TRANSFORM and NYXDB keeps them fresh through PSI — its Predicate Subscription Index — routing only the changes that matter to each subscriber. No external stream processor, no second schema to keep in sync.

  • Materialized views update via event routing, not polling.
  • Historical replay and live tail unify for backfill-plus-follow queries.
  • Handler chaining matches stream:key pairs for precise fan-out.
continuous transform
CREATE TRANSFORM ohlc_1m AS
SELECT
symbol,
window_start(ts, INTERVAL 1 MINUTE) AS bucket,
first_value(price) AS open,
max(price) AS high,
min(price) AS low,
last_value(price) AS close
FROM trades
GROUP BY symbol, bucket;

Disaggregated architecture

Scale compute, memory, and storage independently

NYXDB separates the planes that monolithic databases weld together. Each scales on its own axis — no node-coupled ceilings — while streaming, OLAP, and OLTP share one set of internal contracts.

scales horizontally

Compute

RDMA-accelerated query execution

  • Query and router run as their own images (Dockerfile.query, Dockerfile.router)
  • Add executors to add throughput — independent of storage size
  • Vectorized, columnar execution on the hot path
governor-managed

Memory

Decentralized memory engine

  • The memory governor ramps then blocks admission under pressure
  • The committed tail spills to disk when it exceeds RAM
  • Bounded, elastic — memory is not a per-node hard ceiling
pooled across disks

Storage

NVMe storage engine

  • Declare disks and pools; place data with storage policies
  • Tier hot/cold across pools (memory_data, disk_data, tiered)
  • Grow storage by adding disks — independent of compute
Explore the architecture

distributed, RDMA-accelerated — from the NYXDB product description

The engine

Every primitive markets need, in one runtime

Streaming, querying, indexing, and durability that speak the same internal contract, share the same storage, and deploy from one small image.

real-time

Microsecond reads over fresh writes

In-memory current-state indexes serve the freshest write as the fastest read, while historical scans share the same storage contract — no cache to keep in sync.

Continuous transforms

CREATE TRANSFORM defines standing pipelines that stay fresh through PSI routing — materialized views without a second stream processor.

Counts that are never wrong

Exact, deterministic counts and typed aggregates — auditable math on fresh state, not a sampled estimate you have to caveat.

Keyed tables + read-your-writes

Latest-per-key collapse gives O(1) current state, and reads always reflect the writes that just landed.

Deploy anywhere

One 154MB image spans OLAP, OLTP, and streaming behind a single contract, driven by SQL and a Protobuf DSL.

Performance

Benchmark-first, not marketing-first.

Latency regressions are a release gate. Every hot path ships with a Google Benchmark case and a measured before/after.

~µs
Point read latency
microsecond current-state reads on keyed tables
480k rows/s
Ingest throughput
sustained non-blocking bulk ingest, single node
199 MiB
Boot footprint
lock-free PSI boot vs 3.5 GiB legacy path

▲ TODO-verifyFigures above are drawn from internal engineering targets and prior benchmark runs; they are placeholders pending a published, reproducible benchmark methodology and per-machine-class baselines.

Built for

One engine across the workloads that can't tolerate stale or wrong data.

Docs

From docker run to your first streaming transform.

Install, load data, and build a keyed table with read-your-writes in minutes. Then dig into the concepts: streams, transforms, projections, and the PSI routing model.

first query
docker run -p 8123:8123 nyxdb/nyxdb
# connect your SQL client to :8123
# then:
# CREATE TABLE trades (...) ENGINE = Append;
# CREATE TRANSFORM ohlc_1m AS SELECT ...;