DB
ProductArchitecture

A disaggregated engine — three planes, one contract

Monolithic databases couple compute, memory, and storage to the node. NYXDB separates them so each scales on its own axis — no node-coupled ceilings — while streaming, OLAP, and OLTP share the same internal contracts.

Compute

scales horizontally

Query execution and routing run as their own images — the repo ships Dockerfile.query and Dockerfile.router that build only those targets. Add executors to add throughput; compute capacity is independent of how much data is stored. The hot path is columnar and vectorized, and the product is built for RDMA-accelerated execution.

Memory

governor-managed, elastic

A decentralized memory engine holds current-state indexes and the committed write tail. The memory governor samples pressure and ramps admission at roughly 80% of the limit, then blocks at roughly 95% — backpressure instead of OOM. When the committed tail exceeds RAM it spills to disk, so memory is elastic rather than a per-node hard ceiling.

Storage

pooled across disks

An NVMe storage engine keeps immutable columnar parts. You declare disks and pools and place data with storage policies, tiering hot and cold data across pools. Storage grows by adding disks — independent of compute — and policies decide durability, movement, and compaction per table.

Data path

How a query flows through the planes

  1. 01

    Router

    The router plane accepts the connection and routes the statement to a query executor.

  2. 02

    Compute

    A query executor plans and runs the statement — vectorized, columnar, RDMA-accelerated.

  3. 03

    Memory

    Current-state indexes and the committed tail answer fresh reads; the governor bounds memory.

  4. 04

    Storage

    Immutable parts on pooled NVMe serve history; policies decide tiering and durability.

Storage topology

Declare disks, pool them, place data with policies

Storage topology is first-class SQL. Register disks, group them into pools, and bind tables to storage policies that tier hot and cold data — the storage plane grows by adding disks, not by scaling the whole node.

disks & pools
CREATE DISK fast (path='/mnt/nvme0');
CREATE POOL fast (disks=['fast'], placement='round_robin');
tiered storage policy
CREATE STORAGE POLICY hotcold (
  serve_pool='fast',
  durable={tiers:[{pool:'fast', floor:1}]}
);

DDL shapes follow the engine’s own tests. See the storage operations guide.

One engine, three workloads

Disaggregation is only half the story. Because streaming, OLAP, and OLTP share the same internal contracts — the same tables, the same PSI routing, the same storage — a fresh write is immediately readable, continuous transforms stay current, and historical scans run against the same data. NYXDB is a distributed, high-throughput HTAP engine for large-scale blockchain and analytics workloads, driven by SQL and a Protobuf DSL.

Distributed, RDMA-accelerated, decentralized-memory framing is from the official NYXDB product description; the mechanics above (planes, pools, policies, governor, spill) are the engine’s.

Run the whole engine from one image

Start single-node in a 154MB container, then scale each plane as the workload grows.

Get started Storage model