Storage
Storage policies, disks and pools, part accounting, and how to route tables onto tiers.
Storage in NYXDB is governed by named policies that bind a table to durability, delta flush behavior, index placement, part movement, WAL, and compaction. See the storage model concept for the delta → parts → compaction lifecycle.
Selecting a policy
CREATE TABLE cold (id UInt64, payload String, PRIMARY KEY (id))
SETTINGS storage_policy = 'disk_data';Policies observed in the engine include memory_data, disk_data, default,
tiered, and aged_tiered.
Inspecting storage
Configured policies:
SELECT name, serve_pool, durable, delta, compaction, ttl, tables_using
FROM system.storage_policies;Disks and pools:
SELECT name, pool, path, role, used_bytes, max_bytes, parts, node_id, type
FROM system.disks;Parts (immutable segments):
SELECT part_id, relation, shard_id, rows, size_bytes,
min_key, max_key, disk, created_at_ms
FROM system.parts
WHERE relation = 'trades';Tiering & movement
Tiered policies move parts between pools by age, size, or pressure. The specifics (pool definitions, movement rules, TTL expressions) are policy configuration.
TODO-verify: the policy-definition schema (how pools, movement, and TTL are
declared) is deployment-specific. system.storage_policies exposes each
policy's serve/durable/delta/index/wal/compaction/ttl fields as text.