Skip to content
Calcrivo

etcd Storage Growth Calculator

Project daily etcd storage growth from object creation rate, average object size, and revision history retained per key.

Inputs

objects/day

New/updated objects per day: pods, events, configmaps, etc.

KB
revisions

How many historical revisions of each object etcd retains before compaction.

GB

The configured etcd storage quota (default 2GB, commonly raised to 8GB).

Estimated etcd Growth per Day

4.88MB

Days Until Quota Exhausted

1,678days

Growth per Day

0.0048GB

Step by step

  1. Growth/day = objects × size × revisions

    500 × 2KB × 5

    = 5000KB (4.88MB)

  2. Days until quota exhausted

    8GB ÷ 0.0048GB/day

    = 1678 days

How it works

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

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).

You might also need