A commercial CSI layer is a licensing and architecture model, not a feature. At petabyte scale, per-volume pricing, capacity tiers, and replication overhead are what the model actually costs.
Many OpenShift and Kubernetes platforms run a commercial CSI layer: a proprietary data management platform licensed per volume or by capacity tier, protecting data by replication. That model is straightforward at small scale. At petabyte scale, on dense nodes, running virtual machines and databases, the licensing curve and the replication overhead become the dominant costs. This page looks at the model itself, per-volume pricing and capacity tiers, replication versus erasure coding, and what a migration off it actually involves. It names no product, because the point is the model, not any one vendor.
The Cost of the Model
The problem is rarely the technology. It is how the licence is metered and how much raw hardware the protection scheme demands.
When a CSI layer charges per volume, a platform that provisions thousands of persistent volumes, typical of large OpenShift Virtualization and database estates, accumulates licence cost that tracks object count rather than delivered capacity or value.
Per-volume fees and capacity tiers grow the bill with every workload and every terabyte, independently of the platform budget you have already committed. On dense petabyte-scale clusters the licence can rival the hardware beneath it.
A proprietary data management platform that protects by three-way replication needs three times the raw capacity for the usable capacity you deploy. On NVMe that overhead is a direct, recurring hardware cost, paid on top of the licence.
How simplyblock Approaches It
What Teams Gain
No per-volume meter or capacity tier to model around. The licence tracks the platform you already budget for, so cost stays predictable as volume count and capacity grow.
Erasure coding at 1.5× raw instead of 3× replication cuts the NVMe footprint for the same usable capacity and fault tolerance. Model the split in the calculator.
A per-namespace cutover through standard CSI snapshot and clone means no forklift migration and no application rewrite, with old hardware reclaimed as each namespace moves.
Run the numbers
Enter your usable capacity to compare the hardware and compute footprint, with erasure coding at 1.5× raw instead of 3× for replication. No sign-up, and the result is printable.
With per-volume pricing the licence tracks the number of persistent volumes, not delivered capacity. Large OpenShift Virtualization and database platforms provision thousands of volumes, so the bill grows with object count. simplyblock is priced in line with the platform instead, so volume count does not change the licence.
Three-way replication needs 3× the raw capacity for the usable capacity you deploy. A 4+2 erasure coding scheme needs 1.5×, which is roughly half the NVMe drives for the same fault tolerance, before thin provisioning and compression reduce the footprint further.
Deploy simplyblock alongside the existing storage, define StorageClasses that mirror the current tiers, then migrate workloads per namespace using standard CSI snapshot and clone. Drain the old nodes as each namespace moves and reclaim the drives. Applications keep the same StorageClass and VolumeSnapshot model, so there is no rewrite.
No. simplyblock exposes standard CSI, so PersistentVolumeClaims, StorageClasses, and VolumeSnapshots work as before. The change is at the storage layer and the licensing model, not in the application.
Ask about per-volume and capacity-tier licensing at scale, the erasure-coding capacity difference, or what a per-namespace migration off a commercial CSI layer involves.
Free, no obligation
Book a 30-minute call with a simplyblock storage architect. We will help you cut storage cost and hit your IOPS and latency targets on Kubernetes, with practical recommendations you can act on right away.
Book my session