Skip to content
Calcrivo

StatefulSet Capacity Calculator

Calculate total persistent storage across StatefulSet replicas and estimate the ordered startup time driven by the default OrderedReady policy.

Inputs

pods
GiB
seconds

Time for one pod to reach Ready, including volume attach and readiness probes.

If enabled (podManagementPolicy: Parallel), pods start concurrently instead of one-at-a-time.

Total Persistent Storage

500.0GiB

Full StatefulSet Startup Time

3.8minutes

Startup Time

225seconds

Step by step

  1. Total storage = replicas × PVC size

    5 × 100GiB

    = 500.0GiB

  2. Startup time

    45s × 5 (OrderedReady)

    = 225s

How it works

Each StatefulSet replica gets its own PersistentVolumeClaim via volumeClaimTemplates, so total storage scales linearly with replica count. By default StatefulSets use the OrderedReady pod management policy, starting pods one at a time and waiting for each to become Ready before starting the next — which means full startup time scales linearly with replica count too, unless podManagementPolicy is set to Parallel.

Formulas

Total storage

totalStorage = replicas × pvcSize

R
Number of StatefulSet replicas
V
PVC size per replica in GiB
S
Total persistent storage in GiB

Startup time

startupTime = parallelPodManagement ? podStartup : podStartup × replicas

t_p
Per-pod startup time in seconds
R
Number of replicas
T
Total startup time in seconds

Frequently Asked Questions

Why does StatefulSet startup take so much longer than a Deployment's?

Deployments start all replicas concurrently by default. StatefulSets default to OrderedReady, which is deliberately sequential — this preserves a strict identity/ordering guarantee (pod-0 before pod-1, etc.) that ordered clustered systems like ZooKeeper or Kafka rely on during bootstrap.

When is it safe to use Parallel pod management?

When your application doesn't depend on strict startup ordering for cluster formation — e.g. it handles peer discovery independently. Databases with leader election or ordered bootstrap sequences usually require OrderedReady.

Does scaling down also happen in reverse order?

Yes — with OrderedReady, pods are terminated in reverse ordinal order (highest first), and PVCs are retained by default (not automatically deleted) unless you configure a persistentVolumeClaimRetentionPolicy.

You might also need