Storage & Durability

Memory And SSD

Keys and lookup metadata still require DRAM. Values live in an append-oriented SSD store with immutable record versions. The stable release splits large collections and Streams into grouped records, uses fixed 8 KiB segments for large Strings, and shares long keys through UUID records. These designs reduce whole-value rewriting and bound work for large objects.

Acknowledgements And Recovery

A successful write reply is not a universal power-loss guarantee. Storage flush policy and native asynchronous replication have separate boundaries. WAIT asks for replica acknowledgement of a connection’s write history; it does not create a global durable commit. Choose the policy for your recovery objective and rehearse failure modes.

Clean-shutdown index checkpoints accelerate restart and now cover grouped collections and indirect keys. They complement durable records rather than replace them. RDB SAVE/BGSAVE are logical, node-local exports; scheduled save rules are available, but automatic RDB snapshots remain disabled unless configured. Back up every required Group and the separate Meta/Admin state.

Upgrading From Beta

0.2.0 changes Meta’s Raft persistence and storage internals. Do not reuse beta Meta state as a stable genesis, delete identity markers to force startup, or assume a mixed-version rolling upgrade is supported. Preserve existing state and rehearse a fresh stable deployment with verified data transfer.

Read The Upgrade Notes →

Record CRC policy

In 0.2.0, generation of data-record and value/key extent CRCs is opt-in at startup through record-crc. Existing CRCs are always verified. The no-CRC flag is persisted per object; older readers cannot consume these new objects. Metadata, checkpoint, catalog and replication checks remain enabled.