Calculate how much release history storage accumulates across Helm revisions.
Every `helm upgrade` creates a new revision record while Helm prunes the oldest ones once the count exceeds `--history-max` (default 10; 0 disables pruning entirely). The in-cluster storage cost of this history is simply the number of retained revisions multiplied by the size of each stored manifest, which is why charts with very large rendered manifests should use a lower history-max to avoid unbounded Secret/ConfigMap growth.
storage = maxHistory × manifestSize
Helm retains every revision ever created for that release indefinitely — useful for full audit trails, but storage grows without bound as upgrades accumulate over the release's lifetime.
Yes — once a revision is pruned it can no longer be targeted by `helm rollback <release> <revision>`; only the retained window of recent revisions remains available for rollback.
The default of 10 is reasonable for most workloads; teams that upgrade very frequently (many times per day) often lower it to 3–5 to bound storage, while compliance-sensitive releases sometimes raise it or externalize history to Git instead.