Scaling and Automatic Sizing
You never choose how much capacity a storage gets. The cluster decides it from what the storage actually holds, revisits the decision every night, and keeps enough copies of your data for the value of the data rather than for a number somebody picked once.
A storage is created before it holds anything. At that moment nobody knows whether it will end up holding forty rows or forty million, and asking the person creating it to guess is asking for an answer that is wrong in both directions: too small and it has to be rebuilt later, too large and the cluster pays for room that never fills. So the platform does not ask.
What you get instead is described below. None of it needs configuring, and none of it changes how you write a blueprint. It is worth reading anyway, because a handful of design choices on your side make the automatic behaviour work considerably better.
Decided for you
How much capacity a storage gets, how many copies of it are kept, when that decision is revisited, and what happens when a storage grows past the shape it was given. All of it measured rather than guessed, and all of it live: no downtime, no migration, no maintenance page.
Still yours
How many storages you create and what goes in them, whether data has a natural end date, and telling your operator before you load fifty times more than usual. The cluster reacts to growth quickly, but it reacts: it cannot know about tomorrow's import.
A New Storage Starts at Its Smallest Useful Size
Every storage is created at the smallest shape that works, and grows from measurement instead of from prediction. That is not modesty, it is the cheaper direction to be wrong in.
Capacity set aside for a storage is paid for whether documents arrive or not, and it is paid for on every machine that holds a copy. An empty storage given room for a million documents costs real memory, real recovery time after a restart, and real work on every single query it answers, for as long as it exists. An application with a hundred storages that were each sized for the biggest they might ever get is an application whose cluster is mostly paying for room nobody is using. Growing a storage that turned out to be popular is a solved problem, covered further down. Reclaiming capacity from a hundred storages that never filled is a much worse afternoon.
How Many Copies Your Data Keeps Depends on What It Is
Every storage is held more than once so that losing a machine does not lose data. How many spare copies is not a single cluster-wide number: it is decided per storage, from what that storage means, because the cost of losing it differs enormously and so does the cost of keeping it.
| Kind of data | Spare copies | Reasoning |
|---|---|---|
| Your business data: the storages you create | One | Survives a machine failing. Two copies is what failover requires; a third is a copy nobody ever reads, paid for on every write. |
| Sign-in, sessions, tokens, page definitions | Two | The extra copy is not about durability. It is read on essentially every request, so the copies buy read throughput, and they keep logins working while machines are restarted one by one during an upgrade. |
| Change history and audit trails | One, never zero | A history cannot be rebuilt from the current documents, which is exactly what makes it a history. It is kept for years and it is never treated as disposable, whatever the storage it belongs to is used for. |
| Caches and derived data | None | Rebuildable by definition. Paying to store several copies of something the cluster can regenerate is the one case where a spare copy buys nothing at all. |
| Usage statistics, logs, request history | One | Very high volume, low value per individual record. Worth keeping, not worth keeping three times. |
A storage the platform does not otherwise recognise is treated as business data, which is the careful end of that table. Nothing lands in the cache row by accident.
A Nightly Pass Keeps the Decision Current
A decision made when a storage was empty stops being right the moment it fills, so it is made again every night. Once a day, in a quiet window, the cluster looks at every storage it holds and asks four questions: how large is it, how many documents does it hold, how fast did it grow over the last week and the last month, and how much is it actually read and written.
From those answers it does two different things, and the split between them is the important part.
| Change | Who does it | Why |
|---|---|---|
| The number of copies | The nightly pass, immediately | Adding or dropping a copy is a live background operation. Nothing is rewritten, nothing is taken offline, and it is reversible the following night. |
| The capacity a storage is spread over | Written down as a recommendation for a person | Reshaping a storage moves its contents. That belongs in a window somebody chose, on a cluster somebody is watching, and never in an automated pass at three in the morning. |
Each run leaves a report behind: what it changed, what it recommends, what it skipped and the reason it skipped it. On a new deployment the pass starts in a mode where it reports and changes nothing, so the recommendations can be read against reality for a week or two before anybody lets it act.
What the Nightly Pass Refuses to Do
Something that edits production storage every night is defined at least as much by what it will not do. These are the standing rules, and none of them has an override that runs unattended.
| Rule | What it prevents |
|---|---|
| Never fewer than one spare copy of anything that cannot be rebuilt | An automated pass quietly leaving your only copy of something on one machine. One copy is not a backup and it is not failover. |
| Never reshapes a storage on its own | Contents being moved without anyone deciding it was a good moment. |
| Never runs during business hours | Even adding a copy sends data across the network. It happens while nobody is waiting on a page. |
| Never starts while the cluster is unhealthy or already moving data | Piling work onto a cluster that is already recovering, including from the pass's own previous action. |
| One storage at a time | A run touching everything at once and making its own effects impossible to read. |
| Never more copies than the cluster has machines to hold | Copies that can never be placed, which report as a permanently unhealthy cluster rather than as extra safety. |
| A cooldown of about two days after changing a storage, holding the previous value | A storage being changed back and forth night after night, and a change nobody can undo. Every action carries its own undo record. |
| Reports before it acts, and reports what it did afterwards | Anything happening to your data that is not written down somewhere you can read. |
Growing a Storage Without Taking It Offline
When a storage really has outgrown the capacity it was given, it can be grown in place, and the operation is built so that a failure at any point leaves you where you started.
- Writes to the storage are held briefly.
- A larger copy is built alongside the original. The original stays readable throughout.
- Both sides are counted and compared. A mismatch stops everything here, with the original untouched.
- The name is moved from the old to the new in one single step, so there is never a moment where the name resolves to nothing and writes fail.
- Every other name that pointed at the old storage is carried across with it, so nothing anyone wrote down stops resolving.
It runs on request, by a cluster admin, in a window they picked, and it previews by default: you have to explicitly say "do it" for anything to move. It refuses outright on a cluster that is not fully healthy or is already moving data around, and if a step fails before the switchover, the partial work is removed and the original is unblocked. In the one case where the platform cannot be certain what happened, it deletes nothing and says so loudly, because the worst possible response to an uncertain outcome is a confident cleanup.
Data That Only Grows Is Bounded, Not Enlarged
Some data has no natural end: usage statistics, request logs, an event history. Giving those more room is treating the symptom, because whatever you give them they will eventually fill.
The platform handles its own such data by cutting it into time buckets with a horizon behind it. Statistics are written into a bucket per month and buckets past the horizon are dropped whole, so history stays bounded at roughly the last year plus the current month rather than growing forever. Dropping a whole month is close to free; deleting a year of records one at a time out of one enormous storage is one of the most expensive things you can ask a cluster to do.
The same rule is worth applying to your own high-volume storages. If a storage only ever grows, put a date in the design and decide how far back you actually need, rather than waiting for it to become the largest thing on the cluster. Document expiry covers the per-document version of the same idea.
The Few Things That Are Still Yours
Automatic sizing reacts to what you built. These are the decisions it cannot make for you, roughly in order of how much difference they make.
| Do this | Because |
|---|---|
| Keep one storage per kind of thing, not one per customer, tenant or day | This is the single biggest lever you hold. A hundred storages holding forty documents each cost far more than one storage holding four thousand with a field naming the customer, and no amount of automatic sizing recovers that, because the cost is per storage rather than per document. Filter on a field instead. |
| Delete storages you stopped using | An empty storage is not free. It is observed, copied and kept healthy exactly like a full one. |
| Give data with a natural end an actual end | Sessions, one-time codes, drafts and imports mostly have an obvious expiry. Setting it is cheaper than any capacity decision made later. |
| Warn your operator before a large import | The nightly pass measures what happened yesterday. It handles steady growth well and a fifty-fold jump overnight less well, and a heads-up turns that into a scheduled change instead of a surprise. |
| Leave the recommendations alone unless you are the one running them | The report is deliberately advisory. Anything it recommends moves data, and it is written for a person with a maintenance window, not for the next deploy. |
What Automatic Sizing Deliberately Does Not Do
- It does not shrink a storage on its own. Making a storage smaller is more disruptive than making it larger, so it is always a human decision.
- It does not change your document design. How many fields a document has and what they contain is a modelling question, and a sizing pass has no business having an opinion about it. See Storage Examples.
- It does not tune individual queries. Capacity is a reliability decision. A slow query is a query problem, and Common pitfals is the better starting point.
- It never touches another tenant. The pass is scoped to the entities it is running for, and a recommendation is never derived from anybody else's data.
Next Steps
Storages
The document model underneath all of this: _meta, mutations, queries and the document lifecycle.
Protected Storages
The other half of the storage story: keeping a storage usable by a flow without handing its contents to whoever builds it.
RUAL Core Nano
The single-machine shape, where sizing is a hardware decision you make once.
Frequently asked
Do I have to size a storage in RUAL?
No. Every storage is created at the smallest shape that works and grows from measurement. A nightly pass looks at how large each storage is, how many documents it holds, how fast it grew over the last week and month, and how much it is read and written, then adjusts the number of copies it keeps.
How many copies of my data does a RUAL cluster keep?
It depends on what the data is. Business storages keep one spare copy, sign-in and session data keeps two because it is read on nearly every request, change history never drops below one, caches keep none because they can be rebuilt, and high volume telemetry keeps one. The count is also capped at what the cluster has machines to hold.
Does RUAL reshape a storage automatically?
No. The nightly pass changes the number of copies itself, because that is a live background operation, and writes down capacity changes as a recommendation for a person. Reshaping a storage moves its contents, so it belongs in a window somebody chose on a cluster somebody is watching.
What is the biggest thing I can do to help a RUAL cluster scale?
Keep one storage per kind of thing rather than one per customer, tenant or day. A hundred storages holding forty documents each cost far more than one storage holding four thousand with a field naming the customer, because the cost is per storage rather than per document. Filter on a field instead.