Cloud Run and Cloud SQL Integration: Is the Auth Proxy a Connection Bottleneck?

Question

GoalThe goal is to quantify the potential connection bottleneck when a Cloud Run service talks to Cloud SQL through the Cloud SQL Auth proxy. Each incoming request typically opens a new TCP connection to the database, and Cloud Run’s default maximum concurrency is 80. If each request opens a distinct connection, the Cloud SQL instance may quickly hit its per‑user connection cap, leading to timeouts or throttling.Current UncertaintyThe main uncertainty is whether the Auth proxy implements any form of automatic connection pooling or reuse. Documentation states that the proxy merely forwards traffic, but does not describe implicit pooling. Without explicit pooling in the application code, the number of active connections can grow linearly with request concurrency.Decision PointTo make an informed optimization decision, we need to understand the exact behavior and limits before adding pooling logic.Specific QuestionsHow many concurrent connections can a Cloud SQL instance handle before throttling or rejecting new connections?Does the Cloud SQL Auth proxy automatically reuse connections across requests, or must pooling be handled entirely in application code?What is the recommended pooling strategy (e.g., HikariCP, psycopg2‑pool) to keep the connection count within Cloud SQL limits while maintaining low latency?

Zoha · Answer

The Cloud SQL Auth proxy functions as a pure TCP/TLS forwarder between Cloud Run and Cloud SQL. It does not perform connection pooling or reuse. Each incoming request that opens a new database session creates a distinct connection through the proxy, meaning the number of active connections can scale linearly with Cloud Run's request concurrency.

Cloud Run's default maximum instance concurrency is 80. If your Cloud SQL instance has a per‑instance connection limit at or below 80—and many smaller tiers cap at 100 or less—you can quickly exhaust available slots, resulting in connection errors or timeouts.

Check your Cloud SQL instance's current connection limit (Google Cloud Console → SQL instances → [instance] → Connections tab).
Identify your application runtime (Java, Python, Node.js, Go, etc.) to select a matching pooling library.
Configure an application‑level connection pool (e.g., HikariCP for Java, psycopg2‑pool for Python, node‑postgres pool for Node.js) and set its maximum size to stay below the instance limit while accommodating expected concurrency.
Monitor active connections using Cloud Monitoring metrics ('MySQL:Connections' or 'PostgreSQL:Connections') during load testing to verify the pool stays within bounds.

If the instance tier, application language, or expected traffic pattern changes, the optimal pool size and library choice may shift. To recommend the exact pool size and library for your setup, please provide your Cloud SQL instance tier and application runtime.

Cloud Run and Cloud SQL Integration: Is the Auth Proxy a Connection Bottleneck?

Goal

Current Uncertainty

Decision Point

Specific Questions

1 answer

Your perspective belongs here.

0 question comments