NYXDB is a SQL database. Your tables stay exact as writes land and remember every version, and the derived tables, materialized views and live queries you define are maintained from every committed write, with no stream processor in between.
Capabilities
Six capabilities in one process. Select one to see what it changes for you, and the terms the docs use for it.
Choose per table whether it keeps every row, only the latest state per key, or the latest state plus every accepted version. When writes arrive out of order, the engine settles which version wins.
How it works
Plain SQL, start to finish. The same two tables run through every example on this site and in the docs.
Decide what each table remembers: every event, the latest state per key, or the full history of every change. Shard it by a key and pick the storage layout that fits how you read it.
CREATE TABLE transfers ( chain_id UINT16 NOT NULL, token STRING NOT NULL, sender STRING NOT NULL, recipient STRING NOT NULL, amount UINT256 NOT NULL, transferred_at DATETIME64(3, 'UTC') NOT NULL, _index UINT128 NOT NULL)MODE APPENDSHARD BY (token) SHARDS AUTO;Put STREAM in front of any query and it stays open: you get the answer now, then every change to it as new writes land. No polling, no second system.
STREAM SELECT chain_id, token, SUM(amount) AS volume, COUNT(*) AS transfersFROM transfersGROUP BY chain_id, token;Describe the table you wish you had as a query. A transformation keeps it up to date from every committed write, so the aggregate, the enriched view or the balance is always ready to read.
CREATE TRANSFORMATION balance_activity INTO balances ATTRIBUTE GROUP activity ASSELECT chain_id, recipient AS address, token, COUNT(*) AS transfer_count, MAX(transferred_at) AS last_transfer_at, MAX(_index) AS activity_indexFROM transfersGROUP BY chain_id, recipient, token;The usual stack vs NYXDB
Line by line: what you stop running, and what you get instead. Each row restates a guarantee the docs make.
| Concern | The usual stack | NYXDB |
|---|---|---|
| What you read | A cached copy that lags its source by a hop. | The table itself, fresh on every read. |
| Derived state | Computed by a stream processor, then reconciled against the store. | Kept exact by the engine from every committed write. |
| Schemas | Declared once per system and kept in step by hand. | Declared once, in the table. |
| Yesterday’s state | Rebuilt from logs or snapshots when you need it. | Any versioned table, read as it stood at a past commit. |
| What you run | A database, a queue, a stream processor and a cache. | One process, a configuration file and a data directory. |
| What you write | A dialect per system and an API per hop. | One SQL dialect for tables, derived tables and live queries. |
| When a write shows up | Eventually, once the pipeline catches up. | On the next read, and once to everything derived from it. |
Guarantees, stated on the consistency page. Nothing in this table is a measurement.
Consistency in the docsConnect from anywhere
HTTP for sign-in, one-shot statements and bulk rows; a WebSocket session for everything that stays open; and a TypeScript client that covers both, in the browser and in Node.
Exchange a password or an API key for a session, send one statement and receive its whole result, or push a bounded batch of rows to one table. Plain HTTP, JSON in and out.
# a bearer becomes a sessionPOST /auth/session# one statement, the whole resultPOST /sql# a bounded batch of rows to one tablePOST /write/batchOpen a session once and run finite reads and streaming queries side by side, each tagged by its request id. The server sends only what your client has asked for, so a slow consumer is never flooded and a long stream never blocks a quick read.
# the session token travels in the first frameGET /clientOpenSession → ExecuteSql → ResultBatch → Completed# a streaming query on the same connectionExecuteSql → ContinuousOpened → ContinuousResult …# flow controlDemand · ContinuousDemand · CancelThe TypeScript client speaks both transports: it signs in, opens sessions, sends write batches and resumable bulk loads, and multiplexes cancellable queries over one socket. Integers stay exact, decimals keep their precision and scale, and binary values arrive as bytes.
# one package, both transports@nyxdb/client# every value arrives losslessintegers → bigintdecimals → precision and scale keptbinary → Uint8Array# a password or API key is sent only over https, or to loopbackAttribute groups
Let one pipeline own the balance and another own the activity counters on the same row, with neither able to overwrite the other. A grouped fold writes just one attribute group of a versioned table, each definition writes only what it does not read, and the engine reports lineage per group.
CREATE TRANSFORMATION balance_activity INTO balances ATTRIBUTE GROUP activity ASSELECT chain_id, recipient AS address, token, COUNT(*) AS transfer_count, MAX(transferred_at) AS last_transfer_at, MAX(_index) AS activity_indexFROM transfersGROUP BY chain_id, recipient, token;The questions a technical buyer asks first, including the awkward ones. Anything else is answered in the docs, or in the open on GitHub.
A SQL database. Your tables hold exact current and versioned state, and the derived tables, materialized views and streaming queries you define are kept current from every committed write, inside the engine. There is no separate stream processor to run.
Start a node, create a table, and watch a streaming query follow it. The docs take you from install to your first self-maintaining derived table.