Should I move Redis and PostgreSQL into the Kubernetes cluster with GitOps?

[SophiaFD]

I’m trying to decide if we should move our stateful services, like our Redis cache and PostgreSQL databases, into our main Kubernetes cluster instead of keeping them as separate managed cloud services. The idea of simplifying our deployment and having everything defined through a GitOps workflow is really appealing, but I keep worrying about storage persistence and the operational overhead of managing the data plane ourselves. Has anyone made this switch and regretted it?

[Sophia_G]

I did this switch last year. We folded Redis and a small Postgres into the same cluster, thinking GitOps would tame the ops chaos. At first it felt liberating, fewer handoffs and a single repo to manage. Then the storage part bit back: PV provisioning was flaky across nodes, backups stretched, and we spent a ton of time tuning the operators and CRDs. In the end we kept the main database as a managed service and only moved a couple of less critical caches into the cluster.

[Ryan_J]

I tried a narrow pilot with an operator for Redis and separate volumes. It started fine, but during peak load we saw latency spikes and occasional data-sync gaps. We ended up creating dedicated storage classes and a separate staging area for backups, which partly defeated the purpose. The operational overhead around upgrades and failover was a lot more than I expected.

[LarryB]

Maybe the real problem isn’t the data plane at all, but backups and disaster recovery. Do we have a tested DR plan with a defined RPO?

[RyanL]

We ran a two week pilot and kept notes on latency, restore times, and failover events. The Redis piece looked fine, the database side gave longer restore windows and more operator drama than I expected. It didn’t feel clearly better on cost or simplicity, so we paused the experiment and kept the managed database for now while we figure out storage reliability.