One durability contract for every table and every request: your write is acknowledged only after it is durable in the write-ahead log, and when the receipt returns, the next read sees it. Everything derived from the write hears about it once, after that.
The acknowledgement contract
Three steps, in order, on every table and every request. Select one to see what the node does and what you can read about it.
SELECT relation_id, tablet_id, owner_epoch, committed_frontierFROM system.tablets;Guarantees
The consistency page states them in one table. Here it is, row for row.
| Contract | What it means |
|---|---|
| Atomic statements | A statement is applied completely or not at all. |
| Transactions | BEGIN … COMMIT applies several statements atomically. |
| Read-after-write | The next read after a receipt sees the write. |
| AS OF COMMIT | A read of a VERSIONED table at an earlier commit. |
| Exact derived state | Transformations and materialized views equal their definitions. |
Contracts, not measurements. Each row is stated on the consistency page.
Consistency in the docsRead-after-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 it is published, so its target follows its sources continuously and always equals its definition over them.
UPSERT INTO balances ( chain_id, address, token, amount, updated_at, balance_index, balance_version)VALUES (1, '0x9c2e4f1a', 'USDC', 2500000000, '2026-10-01 12:00:00.000', 1001, 1)ATTRIBUTE GROUP holding;SELECT address, token, amount, updated_atFROM balancesWHERE chain_id = 1 AND address = '0x9c2e4f1a';Atomicity
A write statement changes one row of one table, or one attribute group of it. It is validated completely before it commits, and it commits as a whole; an error names its reason.
Open a transaction and the writes inside it, across groups, rows and tables, become visible together at commit, or are discarded as one.
BEGIN;UPSERT INTO balances ( chain_id, address, token, amount, updated_at, balance_index, balance_version)VALUES (1, '0x4b1e7c2a', 'USDC', 1500000000, '2026-10-01 12:00:00.000', 1001, 1)ATTRIBUTE GROUP holding;UPSERT INTO balances ( chain_id, address, token, amount, updated_at, balance_index, balance_version)VALUES (1, '0x9c2e4f1a', 'USDC', 2500000000, '2026-10-01 12:00:00.000', 1001, 1)ATTRIBUTE GROUP holding;INSERT INTO transfers ( chain_id, token, sender, recipient, amount, transferred_at, _index)VALUES ( 1, 'USDC', '0x4b1e7c2a', '0x9c2e4f1a', 1000000000, '2026-10-01 12:00:00.000', 1001);COMMIT;One owner per tablet
Each tablet has exactly one owner at a time, and its log lives on more than one node.
A table is split into tablets by its shard key. Each tablet has one owner that orders its commits, identified by an owner epoch and a commit sequence, and its records go to a local, segmented, checksummed write-ahead log with group commit.
The log of each tablet is replicated to its replicas on other nodes. When a node is lost, a replica takes over with every write that was acknowledged.
A Raft quorum runs the control plane. Tablets migrate, split and merge at run time as the data grows, and each tablet maps to one write-ahead log domain of its runtime.
Recovery and backups
When the node opens, each tablet picks up exactly where the durable log left off. A backup adds a point-in-time copy you can bring back on a new node.
Each tablet starts from the checkpoint it last completed.
checkpoint_frontier
The write-ahead log suffix written since that checkpoint is replayed on top of it.
replayed_wal_suffix_records
If the process stopped in the middle of writing a record, the torn tail is repaired, and the tablet records that it did.
repaired_torn_wal_tail
The tablet serves again, and each transformation resumes from its own durable cursor, rebuilds from current rows or reseeds, logging its choice.
event=derived_runtime_resume_shape
A backup captures a consistent copy of a node’s tables, their versions and the definitions that maintain them. Restoring it on a new node brings the tables back at the backup’s commit, and transformations resume from their checkpoints. Replication protects against the loss of a node; backups protect against the loss of data.
Health and readiness
The readiness probe answers 200 while the node serves requests and 503 while it drains, and a system relation reports the health of each component.
On a planned stop the node keeps answering reads, tells clients to retry new writes on another node, and waits until every transformation’s durable checkpoint has reached the committed heads of its sources before it exits, logging one line per transformation.
# readiness: 200 while serving, 503 while drainingGET /auth/issuers# a new public write during a drain: retry it on another noderesource_exhausted (HTTP 429)SELECT *FROM system.health_signals;What a technical buyer asks about acknowledgements, visibility and recovery, answered from the docs.
After the tablet’s owner has ordered it, its records have joined a write-ahead log group, and that group has been written to the local log and passed one persistence barrier. Only then is the receipt sent and the write published to everything derived from it.
Start a node, write a row and read it back. The operations docs cover the log, recovery, backups and the probe you wire into your platform.