Should I move production stateful data from Redis to etcd on Kubernetes?

[Edward_L]

I'm trying to decide if we should move our stateful session data from Redis to our managed Kubernetes service's built-in etcd. The idea of simplifying our stack by reducing external dependencies is really appealing, but I keep reading conflicting things about putting production workload data on the control plane's key-value store. Has anyone run their actual application data on it long-term and regretted it?

[Justin75]

We tried moving session data into the Kubernetes control plane store a year ago. It sounded tempting to shrink our stack, but we hit latency and API pressure that spilled over to our apps.

[MilaJ]

In prod we kept sessions in a dedicated external cache instead; upgrades and autoscaling made control plane hiccups visible.

[Paul.S]

We kept sessions on the external cache and added a small TTL for tokens; plus sticky sessions at the edge to reduce churn.

[JacobD]

Does the problem feel real to you? Maybe the real issue is hot spots or invalidation complexity more than the data location.

[Isabella_R]

We measured p95 latency climbing under peak load; the control plane store added noticeable delays, so we abandoned that path.

[Nathan_A]

We did some quick experiments and found the store isn't built for high throughput session data; with etcd specifically the latency and tail became a concern.

[Aurora_T]

Sometimes I drift back to the idea, thinking maybe we could use it for non critical bits, but we haven't gained enough confidence; the team still feels uneasy.