Cloud SQL Auth Proxy and Cloud Run Application Connection Pools: Which Limit Governs Exhaustion Behavior?

Interoperability Boundary

A Cloud Run service uses an application-level connection pool (for example, HikariCP with maxPoolSize=20) while the Cloud SQL Auth Proxy sidecar runs with --max_connections=10. Both components enforce a connection ceiling, but the documented interaction between the two limits is not explicit about which one effectively governs backend connection creation under load.

Constraints and Uncertainty

The Auth Proxy acts as a pass-through forwarder; prior to v1.30.0 it had no --max_connections flag at all. When the flag is set lower than the application pool, excess client connections are queued or rejected, yet the proxy’s own metrics are not directly exposed in Cloud Monitoring. Unix-socket mode can multiplex streams, potentially masking exhaustion until the socket’s internal queue fills. The Cloud SQL instance itself also enforces a tier-dependent maximum, which may be lower than either configured limit.

Open Questions

1. When the application pool size and the Auth Proxy --max_connections differ, which limit determines the point at which new backend connections are refused?
2. Does Unix-socket mode change the effective exhaustion threshold compared with TCP mode for the same configured values?
3. How can an operator reliably observe which component (proxy, application pool, or Cloud SQL instance) is the active bottleneck without adding custom instrumentation?