A production incident occurred when Kubernetes HPA scaled API pods from 3 to 15, while PostgreSQL max_connections remained at 200. With each pod configured with DB_POOL_SIZE=50, the system required 750 connections but only had capacity for 200, resulting in 'FATAL: too many clients already' errors and CrashLoopBackOff states. This failure pattern is common because HPA scales compute without understanding downstream database limits.

The author emphasizes that databases don't autoscale like pods, and connection pools multiply silently until alerts fire. The solution involves calculating real connection math (pods × pool size), flagging unsafe HPA scaling relative to database limits, evaluating connection pooling solutions like PgBouncer or AWS RDS Proxy, and applying HPA caps aligned to downstream capacity. The key lesson is that autoscaling without dependency limits is unsafe, and incident response should be structured rather than relying on tribal knowledge to reduce blast radius during unstable conditions.