How do I know if I’m autoscaling on the wrong signal?

If CPU-based HPA scales but P95 won’t budge—or gets worse—you’ve picked the wrong signal. Switch to RPS, queue depth, or saturation (e.g., DB connection wait time). Tie it to user-facing latency, not host metrics.

What’s the first stateful change to make if I can only do one?

Add `pgbouncer` (transaction pooling) in front of Postgres or a connection pooler for your DB, then cap application connection pools. This alone often cuts P95 100–300ms under load.

Do I need sharding right now?

Probably not. Exhaust pooling, read replicas, and partitioning first. Shard when write amplification or working-set size still crushes the primary, or when a single noisy tenant impacts others.

How do I prove business impact from these changes?

Run a controlled canary with load generation. Track P95, error rate, throughput-at-SLO, and cost per successful request. Tie conversion/retention deltas to the canary window. If you can’t measure it, you didn’t ship it.

Performance-optimization · Dec 1, 2025 · 10 minute read

Kubernetes Added 200 Pods. Postgres Added 600ms: Horizontal Scale That Holds at P95

Your stateless tier will scale until your state makes it cry. Here’s how to design horizontal scale for both—and prove the business impact with user-facing metrics.

Back to all posts

Kubernetes Added 200 Pods. Postgres Added 600ms: Horizontal Scale That Holds at P95

Key takeaways

Implementation checklist