Storage, memory and compute are separate layers of a node. It keeps your data in one layer, the state behind live queries and views in another, and the work that maintains them in a third. Each has its own clauses, keys and system relations, so you grow the one your workload leans on.
Three layers
What each layer holds, the clause or key you turn, and the system relation that reports it.
The write-ahead log, the segments and checkpoints behind it, the row or columnar layout of each table, its partitions, and the policies that retain its rows and tier its data between devices.
The state a shared arrangement or a materialized view holds between commits, charged to the stream’s share of the node’s continuous-state memory and visible in rows and bytes.
The transformations, arrangements and subscribers that apply every committed change once, each on its own durable cursor, with producers never waiting for readers.
Storage
Every commit lands in the write-ahead log before anything else sees it. From there each table declares how it is laid out, bucketed and encoded, and policies decide how long its rows stay and where its data lives over time.
CREATE TABLE transfers ( chain_id UINT16 NOT NULL CODEC(Delta(2), ZSTD(1)), token STRING NOT NULL ENCODING LOW_CARDINALITY, sender STRING NOT NULL CODEC(ZSTD(1)), recipient STRING NOT NULL CODEC(ZSTD(1)), amount UINT256 NOT NULL CODEC(ZSTD(1)), transferred_at DATETIME64(3, 'UTC') NOT NULL CODEC(DoubleDelta, ZSTD(1)), _index UINT128 NOT NULL CODEC(ZSTD(1)), INDEX transfers_ts (transferred_at) USING MINMAX SCOPE HISTORY GRANULE 8192)MODE APPENDSHARD BY (token) SHARDS AUTOPARTITION BY MONTH(transferred_at)ORDER BY (chain_id, token, _index)STORAGE PROFILE COLUMNAR;| Key or clause | Sets |
|---|---|
| node.storage.wal.shard_count | The number of WAL shards per database runtime. Every tablet maps to one shard by a stable hash. |
| node.storage.wal.group_commit_delay_micros | How long the WAL waits to gather a commit group behind one persistence barrier. |
| node.storage.wal.seal_interval_millis · node.storage.wal.seal_bytes | When an open WAL segment is sealed, by time and by size. |
| node.storage.wal.maximum_record_bytes | The largest WAL record one tablet batch may write. |
| … POLICY <name> | Attaches a named policy to a table or an index, for any of the roles every table is bound to. system.table_policy_bindings lists the bindings. |
Memory
A shared arrangement holds the state behind a streaming query or a view so its subscribers receive changes to a result that is already computed. Window and aggregate state is charged to the stream’s share of the node’s continuous-state memory, and the share is visible in the stream’s metrics.
STREAM SELECT window_start, window_end, SUM(amount) AS volumeFROM HOP(transfers, transferred_at, INTERVAL 1 MINUTE, INTERVAL 1 HOUR)EMIT AFTER WINDOW CLOSE;| Setting or key | Scope | What it bounds |
|---|---|---|
| subscriber_idle_ttl | node · definition · statement | How long a shared continuous arrangement stays ready after its last subscriber leaves, so a returning subscriber joins without reseeding. |
| max_stream_duration | node · session · statement | Caps the total lifetime of one WebSocket request, including a STREAM SELECT. A session or statement may only lower a configured cap. |
| keep_alive | definition | Keeps a view’s arrangement running with no subscriber. Transformations and materialized views always run. |
| checkpoint_class | definition | What a definition recovers after a restart: nothing, its durable progress, or its durable state. |
| result_batch_rows | node · session · statement | The largest number of rows in one page of a finite result. Rows and their order do not change, only the framing. |
| gateway.observability.query_history_entries | node | How many recent queries the process keeps in memory for query history; it starts empty after a restart. |
| node.resources.execution.schema_maximum_rungs | node | Schema generations kept per table. |
Compute
Transformations, arrangements and subscribers run on the node and apply every committed change once. Each keeps its own durable cursor and acknowledges only what it applied, so a producer never waits for a reader.
A transformation records its progress durably. After a restart it continues from its cursors, rebuilds from current rows or reseeds from a snapshot, whichever is the cheapest exact way, and logs its choice.
system.transformation_revisions · rows_written · lag_source_sequences
Shared continuous channels and materialized views run as arrangements that subscribers join. The engine sizes query and seed parallelism, chooses join strategies and prunes shards itself, so those choices need no setting.
system.psi_arrangements · generation · checkpoint sequence
Streams, indexes, projections, caches and the change feed each read the feed by relation, component and key. Delivery is admitted per owner against the feed’s retention capacity, so one consumer cannot grow the retained feed without bound.
system.psi_streams · demand · queued frames · lag
node.storage.recovery_workers sets how many relations recover at once when the node opens · node.lifecycle.stop_drain_seconds bounds the drain in which every transformation catches up with its sources before the process exits
What that means for you
Each layer has its own clauses, keys and system relations, so the knob you turn matches the pressure you see.
Partition by time, choose a columnar layout and codecs per column, and let retention policies expire rows by age and storage policies tier data between local devices and object storage. Watch live WAL bytes and the reclamation blockers.
Every client on the same query joins one shared arrangement, so its state is held once. Read each arrangement’s rows and bytes, and set how long it stays ready after the last subscriber leaves.
Each transformation is its own subscriber with its own cursor, and a slow one never holds back a write. Follow each one’s lag and rows written per revision, and bound the drain on a graceful stop.
Tablets are replicated across nodes and move, split and merge as data grows; when a node is lost, a replica takes over with every acknowledged write.
Deployment topologiesThe questions an operator asks before a node carries production traffic. Anything else is in the operations docs.
No. Producers never wait on consumers. Each transformation, index and stream keeps its own durable cursor and acknowledges only what it applied; a slow one falls behind on its own cursor and catches up, and after a restart it resumes from where it left off.
Start a node, read its storage, arrangement and transformation relations, and set the keys that bound each layer.