Consistency and visibility
The exact boundary of statement atomicity, read-your-writes, durability, temporal reads, and unsupported transactions.
NYXDB currently provides tested single-operation visibility in one EngineHost.
That boundary is intentionally narrower than a transactional database with
multi-statement snapshot isolation.
What a successful statement means
For one DDL or DML statement:
- validation completes before publication;
- a multi-row or multi-shard DML batch becomes visible as one committed unit;
- readers do not observe the statement's tentative pre-journal state;
- a failed durable append restores the store and journal tail;
- the next read on the same node observes the committed write.
This is the statement-level read-your-writes contract. It includes the committed tail, so a row does not have to flush into a part before a query can see it.
Attribute-table projections are maintained asynchronously, but default latest reads overlay the not-yet-folded value-stream suffix. Projection lag therefore does not make a successful write disappear from the next latest read.
What is not provided
BEGIN, START TRANSACTION, COMMIT, ROLLBACK, savepoints, and selectable
transaction isolation levels are rejected with a dedicated unsupported-
transaction diagnostic.
| Contract | Status |
|---|---|
| Atomic visibility of one tested statement/batch | Experimental |
| Read-your-writes on the same single-node host | Available within the statement boundary |
| Multi-statement transactions | Design-only |
| MVCC snapshot isolation | Design-only |
| Cross-node linearizability or replica consistency | Unsupported |
Do not describe the current engine as offering ACID transactions or MVCC. A statement can read several relations, but there is no user-selectable, long-lived snapshot spanning multiple statements.
Read frontiers
A relation read captures the part set and committed-tail boundary that belong to one publication frontier. Flush, compaction, and committed-tail drain cannot silently create a gap between those sources. Cross-shard statements publish their participating shard heads at one operation boundary.
This protects a query from seeing half of a committed batch. It does not create a transaction spanning later queries or writes.
Durability is a separate choice
Visibility and durability answer different questions:
- Visibility: has the operation been published to this host?
- Durability: which local bytes are stable after a process, OS, or power failure?
ephemeral_memory publishes rows but does not journal them. Durable policies
journal rows; sync_disk forces fsync before acknowledgement, while asynchronous
policies follow the global --wal-sync posture. See
Durability for the failure matrix.
Streaming continuity
Streaming queries deliver an initial snapshot followed by live changes. That surface is Experimental: local snapshot-to-tail convergence is tested, but reconnect continuity, distributed resume, and an exactly-once delivery SLA are not production contracts. Applications must treat a disconnect as a reason to re-establish and reconcile the subscription.