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.

Get startedHow it works

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

nyxdb — trading.sql
nyx>
1.53M rows/s
durable ingest / core
single core · 1M-row batches, best durable mode
800+
native functions
built in
O(1)
keyed counts
always exact
98.3ns
point read, warm postings
measured median, server-class
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.

1.53M rows/s
durable ingest, single core
1M-row batches, best mode of the durability sweep
vetted table
268ns
keyed count() — O(1) maintained counter
flat from 1k to 16k keys
vetted table
~1510×
skip-index pruning (minmax, 16 parts)
zero disk bytes on pruned reads
vetted table

Measured 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.

Built for

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

Market data & trading analytics

Microsecond reads over fresh writes for order books, ticks, and PnL.

Learn more

Blockchain & on-chain analytics

Decode, index, and query chain state with exact, never-wrong counts.

Learn more

Real-time dashboards

Continuously-materialized serving tables — live, not polled.

Learn more

Observability & logs

Continuous transforms turn raw events into live metrics and views.

Learn more

Product & event analytics

Clickstream and event ingest with sessionized rollups and live product metrics.

Learn more

HTAP & operational analytics

OLTP point access and OLAP scans on one engine — layout per table.

Learn more

Caching & real-time serving

In-memory keyed tables as a SQL cache: µs reads, read-your-writes.

Learn more

Time-series & monitoring

High-rate ingest, tumbling-window downsampling, and lazy TTL.

Learn more

IoT & telemetry

Line-rate ingest of device streams with keyed current-state reads.

Learn more

Fraud & risk

Read-your-writes state for real-time scoring on the write path.

Learn more

AI & vector search

Embeddings, HNSW ANN, and streaming RAG in SQL — no separate vector DB.

Learn more
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.

Getting startedCore concepts
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 ...;