Project etcd database growth as cluster objects and revision history accumulate.
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.
growthPerDay = objectsCreatedPerDay × avgObjectSize × avgRevisions
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.
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.
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).