etcd Storage Growth Calculator
Project etcd database growth as cluster objects and revision history accumulate.
About etcd Storage Growth Calculator
etcd retains historical revisions of every key until compaction runs, so storage growth is driven not just by object count but by how many revisions of each object accumulate between compactions — a frequently updated object (like a Deployment status or an Event) contributes far more to growth than its single-object size suggests. This calculator projects daily growth from creation/update rate, average object size, and retained revisions, and estimates when that growth would exhaust a configured quota-backend-bytes limit.
Formula
growthPerDay = objectsCreatedPerDay × avgObjectSize × avgRevisions
- O_d
- Objects created or updated per day
- S_o
- Average object size in KB
- R_v
- Average revisions retained per object
- G
- Daily etcd storage growth in KB
Worked example
With the default values below, etcd Storage Growth Calculator returns Estimated etcd Growth per Day of 4.88. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Objects Created per Dayaccepts 0–10,000,000 objects/day
- 500 objects/day
- Average Object Sizeaccepts 0–10,000 KB
- 2 KB
- Average Revisions Retained per Objectaccepts 1–100,000 revisions
- 5 revisions
- etcd Quota (quota-backend-bytes)accepts 0.1–1,000 GB
- 8 GB
Results
- Estimated etcd Growth per Day
- 4.88 MB
- Days Until Quota Exhausted
- 1,678 days
- Growth per Day
- 0.0048 GB
Step by step
- 1Growth/day = objects × size × revisions= 5000KB (4.88MB)
- 2Days until quota exhausted= 1678 days
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 4 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why does etcd need periodic compaction?
Every write to a key creates a new revision rather than overwriting in place, so without compaction (which removes old revisions below a retained history threshold) the backend database grows unboundedly even if the number of distinct objects stays constant.
What happens when etcd hits its storage quota?
etcd goes into a maintenance-required alarm state and starts rejecting writes cluster-wide — this is a control-plane outage, since the API server can no longer persist new state, so proactive monitoring of db size is critical.
What commonly causes runaway etcd growth?
Excessive Event object churn (from crash-looping pods or noisy controllers), disabled or infrequent compaction, and defragmentation not being run after compaction (compaction frees logical space but defrag is needed to reclaim it on disk).