Should I use kubernetes persistent volumes for redis and stateful apps?

[Steven12]

I’m trying to decide if we should move our stateful services to Kubernetes, but I keep hitting the same mental block about persistent storage. Our current setup uses managed database services, but for things like our Redis caching layer and a few legacy apps, the idea of managing persistent volumes with a cloud-native storage class feels like we’re just reinventing a less reliable wheel.

[Scott4]

I’ve been there. We tried Redis in Kubernetes with PVCs backed by the cloud storage class. It ran, but we hit occasional IOPS spikes and longer failover times when a node or zone hiccuped. Backups and restoring Redis data were a pain because you’re chasing the right snapshot cadence. After testing, we moved to a managed Redis service and kept only the stateless bits in the cluster. The performance and reliability difference felt real, and we stopped wrestling with the storage tier.

[EthanHM]

To be honest, if you can tolerate the extra ops, using a Redis operator or a StatefulSet with a solid CSI driver could work, but I’m not confident about the long-term cost of maintenance. The pain usually isn’t the storage API itself; it’s the guarantees around latency, backups, and recoveries when things go wrong.

[Stephen_L]

Maybe the root issue isn’t where the data lives but how the apps are deployed and updated. If the legacy apps hate restarts or migrations, Kubernetes storage becomes the bottleneck you notice most. It might be worth isolating the cache and legacy apps from the data plane and focusing on reliability patterns instead of chasing a perfect storage class.

[Zoey2]

I once got sucked into a storage-class debate and spent weeks tuning PVCs, quotas, and replication. Then I realized the gains came from separating concerns: run hot caches as managed services, move durable data to proven DBs, and only keep the noncritical bits in the cluster. It didn’t feel tidy, but it moved us forward despite the mess.