Large saves

The honest starting point#

Very large single documents (tens of megabytes) are written whole. There is no streaming or incremental save path, and the framework does not pretend otherwise: a save is a document, and a document is materialised to be verified, compressed and encrypted as one unit. See Limitations.

The ceilings that apply#

Set these to something your game can actually produce. A ceiling nothing can fit under protects nothing, and the validation report flags both a ceiling that is too low and one that is too high to mean anything.

If your save really is large#

1. Split by slot. Slots are directories; a game with a large world can save regions or chapters into separate slots and load the one it needs. That is the intended answer and it uses no new machinery.
2. Save the state, not the content. Content belongs in the build; a save should hold what a player changed. Most "huge saves" are a capture that included authored data.
3. Turn on compression — Deflate before encryption, and measure. On the reference model it reduced 91 KB to 6.1 KB and made the whole save faster.
4. Offload the write with Storage.OffloadWritesToThreadPool if the projection is not the bottleneck but the write is.
5. Raise the ceiling deliberately and record why, so the next person knows it was a decision.

Next#

• Performance — the measured costs, and how to reproduce them.
• Configuration reference — every limit with its meaning.
• Limitations — what the framework does not offer, stated up front.