Should I move Redis and PostgreSQL into a Kubernetes cluster?

[RobertVG]

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 potential cost savings are tempting, but I keep worrying about the operational overhead of managing storage classes, persistent volumes, and ensuring high availability ourselves. Has anyone else made this switch and regretted it later?

[OliviaUH]

I actually did this last year. moved Redis and PostgreSQL into the main cluster to chase cloud spend. the promised savings looked good on paper, but the ops debt piled up fast. PVs, storage classes, and ensuring high availability by ourselves turned into full time work. backups, DR drills, node drains, failovers—everything felt brittle until we got a proper runbook. Not a slam dunk.

[Jonathan.M]

We did it and regretted it after a big incident. Our in-cluster Redis got stressed during a retry storm, and replication lag popped up because we didn't have the same pacing as managed services. Helm charts and operators helped, but backups and restore tests remained flaky. Eventually we moved those workloads back to managed services.

[ScottYR]

We kept PostgreSQL managed but tried a small Redis inside Kubernetes to test the waters. The cost delta looked good at first, but storage tuning, PVC churn, and long-running backups still took a chunk of SRE time. Not a clean win, but for a team with tight ops bandwidth it may pencil differently.

[Riley96]

Sometimes I wander into the cost charts and wonder if the real problem isn't the database location at all but how data grows and how we back it up. We flirted with monoliths in the cluster and then snapped back to managed services because the risk felt bigger than the savings. It still nags at me, though—are we solving the wrong thing by moving storage around?