Introduction

NYXDB is a low-latency HTAP database engine for single-node streaming, analytical, and operational workloads.

NYXDB combines SQL execution, local durability, in-process table sharding, streaming subscriptions, continuous transforms, and vector search in one runtime. The current production candidate is the single-node all-in-one nyxdb process. It is designed for low-latency workloads such as market data, on-chain analytics, telemetry, and observability.

Know the current boundary: clustering, replication, high availability, failover, and multi-statement transactions are not supported by the current runtime. Streaming, continuous transforms, drivers, and wire formats are functional but pre-GA. Direct application endpoints, auth/governance, and operator access controls are also Experimental; native TLS and direct-public zero-trust deployment are unsupported. Read Capabilities & status before planning a deployment.

Choose your path

Get started

Run a single node and issue verified queries in a few minutes.

Capabilities & status

Implemented, experimental, design-only, and unsupported boundaries.

Core concepts

Tables, transforms, streaming reads, storage, indexes, and PSI.

Direct application access

Publish typed read-only queries for browsers and platform clients without a custom query proxy.

SQL reference

Statement syntax, data types, and native functions.

Drivers & protocol

nyxsql, JDBC, the web console, and experimental wire contracts.

Operations

Persistence, recovery, memory, storage, and observability.

What the engine provides today

Three table models — append history, latest-per-key state, and typed bitemporal attributes share one catalog and query path.
Local durability and recovery — the all-in-one process owns catalog/DML journals, immutable NYXP parts, restart replay, and compaction. The separate nyxdb-backup operator CLI provides on-demand verified backup, restore, and journal-sequence PITR for the single-node default disk.
In-process sharding — a table can use multiple shards inside one process; this is parallelism, not a distributed cluster.
PSI event routing — the Predicate Subscription Index routes committed changes by exact stream:key identity to engine subscribers.
Experimental real-time surfaces — STREAM SELECT, shared channels, and continuous transforms are executable and tested, while their compatibility contract remains pre-GA.
Experimental application access — operators can publish typed one-shot or live read queries, map tokens to server-trusted claims, grant logical views, and enforce process-local limits without exposing end-user SQL or writes.
Separate operator governance — engine-managed users, opt-in --require-auth, operator-only grants, and a volatile enforcement log govern database operators independently from application roles.

Compatibility promise

Every public surface in these docs is labeled against the engine's executable capability matrix. Implemented means it is available in the all-in-one profile and has a conformance target. Experimental means it works and is tested, but its interface or operational contract may still change. An accepted architecture decision is not, by itself, evidence that a capability ships.

The source of truth is the engine repository's capability matrix.