Transactions and isolation

Status: multi-statement transactions are Design-only

The current engine provides visibility and durability around one accepted statement. It does not expose an MVCC snapshot-isolation contract across requests.

Unsupported statements

The parser explicitly rejects:

BEGIN;
START TRANSACTION;
COMMIT;
ROLLBACK;
SAVEPOINT before_changes;
RELEASE SAVEPOINT before_changes;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

The diagnostic code is NYXDB_PARSE_UNSUPPORTED_TRANSACTION.

What is guaranteed

• A successfully published statement is observed according to the table's statement-visibility path.
• One multi-row insert is validated and committed as one statement.
• Keyed mutations do not expose a partially replaced current row.
• Durable acknowledgement follows the target storage policy and configured WAL sync mode.
• A query executes against the engine snapshot selected for that operation.

These properties do not compose multiple statements into a transaction.

Application design

• Put rows that must commit together in one supported statement.
• Use stable request identifiers and idempotent retry logic at the application boundary.
• Model workflows as append events or explicit keyed state transitions.
• Do not implement read-modify-write correctness by assuming a client-held snapshot remains stable between requests.
• Verify an ambiguous connection failure by reading application state before retrying a non-idempotent write.

For the durability/visibility distinction, see Consistency.