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

Answer to the Core Question

When the application‑side pool size and the Cloud SQL Auth Proxy --max_connections differ, the first component to reach its ceiling determines when new backend connections are refused. In practice, the lowest of the three limits—the proxy’s --max_connections, the application pool’s maxPoolSize, and the Cloud SQL instance’s tier‑specific max_connections—becomes the bottleneck. If the proxy’s limit is lower than the pool, the proxy will queue or reject connections before they hit the database. If the proxy’s limit is higher, the application pool governs until the instance’s own limit is reached.

Confirmed Facts

• The Auth Proxy introduced the --max_connections flag in v1.30.0; earlier versions had no proxy‑side cap.
• Both TCP and Unix‑socket modes honor the same numeric limit, but Unix sockets can multiplex logical connections over a single file descriptor, delaying observable exhaustion until the socket’s internal queue fills.
• The Cloud SQL instance’s tier imposes a hard max_connections ceiling that supersedes both proxy and pool limits.

Likely Explanation for Common Observations

In many deployments, developers notice increased latency or connection‑wait times before any database error, indicating the proxy is the active limiter. Conversely, if the pool size is the smallest value, the application will experience “connection pool exhausted” errors from the driver before the proxy ever logs a rejection.

How to Verify Which Component is the Bottleneck

1. Check the Cloud SQL instance tier. Use gcloud sql instances describe INSTANCE_NAME --format="value(settings.ipConfiguration.ipv4Enabled)" to confirm the instance’s max_connections value.
2. Enable proxy debugging. Run the sidecar with --debug or --log-level=debug to surface metrics such as proxy_connections_active and proxy_connections_waiting in the container logs.
3. Instrument the application pool. Most drivers expose pool metrics (e.g., HikariCP’s activeConnections and idleConnections). Log these values or export them to Cloud Monitoring.
4. Generate a controlled load. Use a tool like wrk or ab to open more concurrent connections than the proxy limit and observe where the first failures occur.
5. Compare TCP vs Unix‑socket. Repeat the test with the proxy in Unix‑socket mode (--socket-path=/cloudsql/PROJECT:REGION:INSTANCE) and note any delay in failure symptoms; the numeric threshold should remain unchanged.

Missing Diagnostic Detail That Could Change the Recommendation

Could you confirm the Cloud SQL instance’s tier and its configured max_connections value? If that value is lower than either the proxy or the pool, the instance itself becomes the governing limit.