Storage Optimization
How DevZero rightsizes PersistentVolumeClaims -- expanding capacity before a PVC fills up, and shrinking it when usage no longer justifies the current size.
Storage Optimization
Storage optimization applies the same idea as CPU/memory rightsizing -- match allocated capacity to actual usage -- to PersistentVolumeClaims. DevZero tracks how a PVC's used bytes grow over time and recommends expanding it before it fills up, or shrinking it when usage has settled well below its provisioned size.
There's no review/approve step for storage recommendations -- once one is generated, it's applied immediately. The Action Triggers field controls how it gets generated in the first place: On Schedule and On Detection policies generate and apply recommendations on their own, while a Manual policy only generates one when you click Apply one-time optimization on a PVC in the dashboard -- and that click generates and applies it in the same step.
Growth Model
DevZero fits a linear regression over a PVC's historical used_bytes (collected by the Read Operator) to project when it will run out of space.
- Lookback window -- how much history to fit the regression against.
- Confidence score -- derived from the regression's R² and the number of data points available. Recommendations from a low-confidence model are skipped.
- Days to full -- the growth rate projected forward from the current usage to the current capacity.
If usage is flat or decreasing, days-to-full is treated as effectively infinite and DevZero evaluates the PVC for a shrink instead.
Storage Policy
A storage policy configures how aggressively DevZero rightsizes PVCs. Configure policies from the dashboard under Optimization → Policies → Storage Policies.
| Field | Default | Description |
|---|---|---|
| Action Triggers | On Schedule | When the policy runs: manually, on a cron schedule, or on detected changes. |
| Cron Schedule | 0 2 * * * | Schedule for On Schedule triggers. |
| Lookback Period | 7 days | How much usage history to fit the growth model against. |
| Min Data Points | 100 | Minimum data points required before a recommendation is generated. |
| Target Utilization | 80% | The utilization DevZero rightsizes toward. Expand recommendations add headroom above it; shrink recommendations reduce capacity toward it. |
| Days to Full Threshold | 30 | If a PVC is projected to fill within this many days, DevZero recommends expanding it. |
| Critical Days to Full | 7 | Below this threshold, the recommendation is flagged critical priority. |
| Headroom Days | 14 | Days of projected growth added on top of current usage when sizing an expansion. |
| Max Expansion per Action | 50% | Caps how much a single expansion can grow a PVC, regardless of what the growth model projects. |
| Min Resize Increment | 1 GiB | Recommendations smaller than this are skipped -- avoids resizing for negligible gains. |
| Max Monthly Cost | -- | Optional ceiling on the recommended size's estimated monthly cost. Recommendations that would exceed it are suppressed. |
| Cooldown Window | 24 hours | Minimum time between consecutive resize actions on the same PVC. |
Expanding a PVC
Expansion is a standard Kubernetes in-place volume resize: DevZero patches spec.resources.requests.storage on the PVC and waits for the CSI driver to report the new capacity.
Expansion requires a StorageClass with allowVolumeExpansion: true. If the StorageClass doesn't support it, the recommendation is marked blocked and no resize is attempted.
DevZero only recommends an expansion when the PVC is projected to fill within the Days to Full Threshold. The recommended size is the current usage plus Headroom Days of projected growth, rounded up to the Min Resize Increment, and capped by Max Expansion per Action.
Shrinking a PVC
Kubernetes doesn't support shrinking a PersistentVolumeClaim in place -- the API rejects any decrease to spec.resources.requests.storage. To free unused capacity, DevZero migrates the PVC's data to a new, smaller volume instead.
A shrink is only recommended when:
- The PVC is projected to stay well below capacity (more than 90 days to full)
- Shrinking would free at least 25% of current capacity -- smaller savings aren't worth the migration risk
- Doing so wouldn't cause the PVC to fill again within the Days to Full Threshold
- The PVC belongs to a resolvable workload (Deployment or StatefulSet) -- orphan PVCs with no owning workload are never shrunk
See PVC Shrink Migration for how the migration itself works, including StatefulSet handling and rollback behavior.
Cost Estimation
Each recommendation includes an estimated current and recommended monthly cost, calculated from a built-in reference price per GiB for common storage classes:
| Provider | Storage Class | Approx. $/GiB/month |
|---|---|---|
| AWS | gp3 | $0.08 |
| AWS | gp2 | $0.10 |
| AWS | io1 / io2 | $0.125 |
| GCP | pd-standard | $0.04 |
| GCP | pd-balanced | $0.10 |
| GCP | pd-ssd | $0.17 |
| Azure | standard-lrs | $0.05 |
| Azure | standardssd-lrs | $0.075 |
| Azure | premium-lrs | $0.135 |
These are DevZero's built-in reference prices, not a live billing integration. Set Max Monthly Cost on a policy to suppress recommendations whose estimated cost would exceed it.
Live Migration
How DevZero applies resource changes to running pods using CRIU checkpoint-restore, preserving in-memory state and open connections without an application restart.
PVC Shrink Migration
How DevZero shrinks an over-provisioned PersistentVolumeClaim by migrating its data to a smaller volume, including StatefulSet handling and rollback.