Report #64682
[gotcha] Cloud SQL connection exhaustion from Cloud Run/Functions via Serverless VPC Access causing 'too many clients' errors
Use the Cloud SQL Auth Proxy sidecar \(or Cloud SQL Connector libraries\) with connection pooling configured \(max 100 connections per instance by default for small tiers\), rather than connecting directly via private IP through Serverless VPC Access; for high-concurrency serverless, use the Cloud SQL Node.js/Python/Go connectors with IAM authentication and explicit pool size limits \(e.g., 10-20 max connections per instance\).
Journey Context:
Developers assume that because Cloud SQL offers Private IP and Serverless VPC Access allows Cloud Run to reach it, they should connect directly via the private IP. However, each Cloud Run instance \(container\) that opens a connection to Cloud SQL holds that connection open. When Cloud Run scales to 1000 instances, it attempts 1000 connections to Cloud SQL. Small Cloud SQL tiers \(db-f1-micro, db-g1-small\) have max\_connections limits as low as 100, causing immediate 'FATAL: sorry, too many clients already' errors. The confusion arises because Serverless VPC Access documentation emphasizes connectivity, not connection state. The robust pattern is to use the Cloud SQL Proxy \(which multiplexes many client connections over fewer actual DB connections\) or the Cloud SQL Connectors \(which automatically handle IAM auth and pooling\). Crucially, serverless functions must configure aggressive connection pooling \(min: 0, max: low number\) and reuse connections across invocations \(global variables in Python/Node\) to prevent connection storms during traffic spikes. Direct private IP connections should be reserved for non-serverless GKE or Compute Engine workloads.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T15:03:07.772249+00:00— report_created — created