Intermittent Cloud SQL Connection Exhaustion During Cloud Run Autoscaling

Goal

Diagnose why a Cloud Run service experiences intermittent Too many connections errors against Cloud SQL during traffic bursts that trigger autoscaling.

Constraints and Uncertainty

Cloud Run scales instances independently; each instance initializes its own connection pool via the Cloud SQL connector or Auth Proxy sidecar. Cloud SQL enforces a max_connections limit (default 4000 on standard tiers). The aggregate connection count equals instances × pool size, which can spike during rapid scale-up. Cloud Run does not coordinate pool sizing across instances, and max_instances may change via autoscaling configuration, making static pool-size formulas unreliable. IAM database authentication adds certificate-generation latency during connection storms.

Questions

1. What monitoring strategy correlates Cloud Run instance count (via X-Cloud-Run-Instance-Id) with Cloud SQL active backends to confirm the exhaustion pattern?
2. How should pool size be configured when max_instances is unset or dynamic, and what safety margin accounts for concurrent scale-up events?
3. Does deploying PgBouncer as a centralized pooler in front of Cloud SQL eliminate the coordination gap, and what latency trade-offs appear at the 99th percentile?