Consistency and visibility

NYXDB commits every statement atomically, and groups several statements into one atomic unit with a transaction. This page states the guarantees an application builds on.

One statement, one atomic write

A SQL write statement changes one row of one table: INSERT, UPSERT and REPLACE carry one row tuple, and UPDATE and DELETE name one complete primary key. With a trailing ATTRIBUTE GROUP, it changes one attribute group of that row. The write is validated completely before it commits, and it commits as a whole. An error names its reason, for example "insert target already exists" for an INSERT of an existing key.

Each tablet orders its own commits with a commit sequence and acknowledges a write once its record is durable in the write-ahead log. See Durability.

Transactions

BEGIN … COMMIT groups writes across attribute groups, rows and tables into one atomic unit; ROLLBACK discards them. See Transactions.

Reads after a write

When a write returns its receipt, the next read sees it, with no retry. A read that runs while a write is in flight returns either the state before that write or the state after it, never a partly applied row.

A transformation or materialized view applies each source commit as PSI publishes it, so its target follows its sources continuously and always equals its definition over them.

Snapshots: AS OF COMMIT

AS OF COMMIT <n> reads a VERSIONED table as it stood at commit n:

SELECT address, token, amount
FROM balances AS OF COMMIT 42
WHERE chain_id = 1;

See Versioned tables.

Guarantees

Streaming reads

A STREAM SELECT delivers one snapshot of its result, then the changes that later commits make to it. See Streaming reads for the delivery contract.