Should we move Redis and PostgreSQL into our Kubernetes cluster?

[Oliver.L]

I’m trying to decide if we should move our stateful services, like our Redis cache and PostgreSQL databases, into our main Kubernetes clusters instead of managing them as separate cloud provider services. The idea of having a unified control plane is appealing, but I keep worrying about persistent storage and handling node failures gracefully.

[Ava.R]

I tried moving Redis and Postgres into the cluster last year. It looked clean on paper, but persistent storage and node failures got messy fast in Kubernetes. We used StatefulSets and a storage class, but when a worker node failed the PVCs didn’t fail over cleanly and we hit a write stall during recovery. We added nightly backups to object storage and a DR runbook, and we learned to tune pod disruption budgets and storage performance isolation. The unified control plane was appealing, but the day-to-day storage churn and recovery windows ate into sprint velocity.

[LoganCL]

We kept them as managed services and kept the cluster lean. Auto backups, patch windows, and built-in failover save a lot of drama and time. The flip side is data gravity and cross-region failover—moving large datasets between regions costs money and adds latency, and we still had to tune how apps talk to the DB and cache to avoid hot paths.

[TylerH]

Is the real problem the storage layer, or is our apps' data access patterns? I keep circling back to whether the bigger win is better architectures, demand shaping, or smaller, more forgiving reads. I keep wondering if a separate persistence layer is masking a deeper issue.

[PenelopeNW]

We did a tiny pilot, one Redis node inside the cluster, and observed higher latency under peak, plus a few outage scares during restarts; we halted the pilot and stayed with managed services.