Skip to content
Calcrivo

PVC Size Calculator

Size a Kubernetes PersistentVolumeClaim from current data size, daily growth rate, retention period and a safety margin.

Inputs

GB

Data already stored on the volume today.

GB/day

Expected additional data written per day.

days

Planning horizon before the volume will be resized or rotated.

%

Extra buffer to avoid hitting 100% disk usage before the next resize.

Recommended PVC Size

193.8GB

Recommended PVC Size

180.4GiB

Projected Data at End of Retention

155.0GB

Total Growth Over Retention

135.0GB

Step by step

  1. Projected growth over retention

    1.5 × 90

    = 135.0 GB

  2. Projected total data

    20 + 135.0

    = 155.0 GB

  3. Recommended PVC size with margin

    155.0 × (1 + 25/100)

    = 193.8 GB

How it works

PersistentVolumeClaim sizing should account for both existing data and expected growth over the planning horizon, plus a safety margin so the volume doesn't fill up before the next resize cycle: size = (current + daily_growth × retention) × (1 + margin ÷ 100). Many storage classes support online volume expansion, but planning ahead avoids emergency resizes or application-level failures from a full disk.

Formula

recommendedSize = (currentData + dailyGrowth × retentionDays) × (1 + safetyMargin / 100)

D_0
Current data size in GB
g
Daily growth rate in GB/day
R
Retention/planning period in days
m
Safety margin percentage
S
Recommended PVC size in GB

Frequently Asked Questions

Can I just resize the PVC later instead of over-provisioning?

If your StorageClass has allowVolumeExpansion: true, yes — but expansion isn't instantaneous and some CSI drivers require a pod restart to pick up the new size, so leaving margin still reduces operational risk.

What safety margin is typical?

20-30% is common for predictable workloads; unpredictable or bursty growth (e.g. log volumes during incidents) often warrants 50% or more.

Should database PVCs be sized differently than log PVCs?

Yes — databases often need extra headroom for WAL files, temporary tables, index rebuilds and vacuum/compaction operations, which can temporarily double disk usage during maintenance.

Does this account for filesystem overhead?

No — reserve additional space for filesystem metadata and reserved blocks (ext4 reserves ~5% by default), especially relevant for smaller volumes where that overhead is proportionally larger.

You might also need