How would you design a StorageClass for a high-IOPS database workload versus a cheap-capacity logging workload?

Define two separate StorageClasses, each with parameters tuned to its underlying cloud/storage backend's performance tiers — a provisioned-IOPS or SSD-backed volume type for the database, and a cheaper throughput-optimized or HDD-backed volume type for logs — and let each workload's PVC reference the appropriate StorageClass by name, rather than relying on a single default StorageClass to serve both needs adequately.

A single generic StorageClass forces a bad compromise: if every PVC in the cluster uses the same default, you're either over-paying for high-performance storage on workloads that don't need it, or under-provisioning performance for the workload that genuinely needs it. StorageClasses exist specifically to let you define multiple named storage profiles precisely to avoid that trade-off — the design work is choosing the right profile per workload, not picking one setting for the whole cluster.

• The database workload needs consistently low-latency, high-IOPS storage, sized to its actual measured I/O pattern.
• The logging workload needs large capacity at low cost per GB, and can tolerate higher latency.
• Each workload's PVC must deliberately reference the storage tier appropriate to it, not silently inherit a cluster-wide default.
• Reclaim behavior should reflect each workload's actual data value (a database's data is expensive to lose; logs are often more disposable).

StorageClass parameters map directly to backend-specific storage tiers: for cloud block storage, this typically means selecting a specific volume type via parameters.type (e.g., io2 for provisioned IOPS versus gp3/st1 for general-purpose or throughput-optimized on AWS EBS) and, where the backend allows it, explicitly setting parameters.iops and parameters.throughput — these parameters are backend-specific, so the actual keys and values depend entirely on which CSI driver and cloud provider are in use.

The database StorageClass should prioritize consistent low-latency IOPS: something like an io2/Premium SSD-class volume type, sized and provisioned-IOPS-tuned to the database's actual measured I/O pattern (not a guess) — over-provisioning IOPS is pure cost waste, under-provisioning shows up directly as query latency.

The logging StorageClass should prioritize cost-per-GB over latency: a throughput-optimized or standard HDD-backed volume type is usually sufficient, since log ingestion is typically sequential-write-heavy and latency-tolerant compared to a database's random-access pattern.

Each workload's PVC explicitly names its StorageClass: spec.storageClassName: database-io-optimized versus spec.storageClassName: logs-cost-optimized — a deliberate, explicit choice per workload rather than relying on whatever the cluster's default StorageClass happens to be.

reclaimPolicy and allowVolumeExpansion are also worth setting deliberately per StorageClass: the database StorageClass likely wants allowVolumeExpansion: true (databases grow and rarely shrink) and a Retain reclaim policy given the value of the data; the logging StorageClass might reasonably use Delete, or have its own separate retention/archival strategy outside of the PV itself.

Maintaining two (or more) StorageClasses instead of one default adds a small amount of ongoing configuration surface — someone has to know which StorageClass to reference for a new workload, and the mapping needs documenting so it doesn't become tribal knowledge. This is a worthwhile trade against the alternative of paying for high-performance storage everywhere or accepting degraded performance where it actually matters. Provisioned-IOPS tiers also cost meaningfully more than general-purpose ones, so sizing them from real measured workload data (rather than a conservative overestimate) matters for keeping the cost difference justified.

• Define separate, purpose-built StorageClasses rather than relying on one generic default to serve workloads with very different performance and cost profiles.
• StorageClass parameters map to backend-specific volume types and performance tiers (provisioned IOPS vs. throughput-optimized) — the actual keys depend on the CSI driver and cloud provider.
• Size IOPS/throughput parameters from actual measured workload patterns, not guesses — over-provisioning wastes money, under-provisioning shows up as latency.
• Set reclaimPolicy and allowVolumeExpansion deliberately per StorageClass based on each workload's actual data-value and growth characteristics.

• Kubernetes: Storage Classes
• AWS: Amazon EBS volume types