Should we move Redis and Postgres into Kubernetes or stay with managed services?

[AbigailT]

I’m trying to decide if we should move our stateful services, like our Redis cache and PostgreSQL database, into our main Kubernetes cluster or keep them as managed cloud services. The idea of simplifying our deployment and having everything defined in git is really appealing, but I keep worrying about storage persistence and the operational overhead if a node goes down.

[AddisonUM]

I tried moving Redis and PostgreSQL into the Kubernetes cluster a while back. We used StatefulSets with persistent volumes and a shared storage class. In practice the storage was the bottleneck: when a node failed, the PVCs took time to recover and we had intermittent write failures until the PVs reattached. We ended up doing frequent backups and drills, and replaced the in-cluster storage with a cloud managed snapshot chain. It felt workable for a cache, but the database side got tense fast.

[Mia.S]

We kept them as managed cloud services. The ops load dropped a lot, but we ran into drift and cost debates. Git declarative definitions helped but you still need separate pipelines for provisioning those services, and every network refactor required testing.

[Charles94]

Do you think the real problem is DR planning rather than where the data lives?

[Stephen25]

Pilot approach: run a tiny Redis on k8s with a single replica and a daily snapshot, monitor failover time, and compare to the managed service metrics. It gave a rough feel but I never trusted it to handle a real failure without manual steps. If you have time, run a 1 hour failover drill and log the latency and error rate.