Report #56385
[gotcha] Cloud SQL 'too many connections' errors despite low application connection count
Avoid Cloud SQL Proxy sidecar pattern for high-density Kubernetes clusters; instead use a centralized PgBouncer/ProxySQL deployment with max 10-20 connections to Cloud SQL, or use Cloud SQL Go/Python connector libraries with connection pooling in the application; ensure 'max\_connections' Proxy flag matches instance tier limits \(default 100 for db-f1-micro\)
Journey Context:
Cloud SQL Proxy provides IAM authentication and SSL tunneling to Cloud SQL instances. When deployed as a Kubernetes sidecar \(common pattern\), each application pod runs its own Proxy instance. Cloud SQL connection limits are per-database-instance \(e.g., 100 for smallest Postgres tiers, scaling with vCPU\), not per-application. In a cluster with 50 pods, each establishing 10 connections through their sidecar, the total 500 connections exhausts the 100 connection limit on a small Cloud SQL instance. The error 'FATAL: sorry, too many clients already' appears in application logs, but 'show max\_connections' on the DB reveals the true limit. Developers often misdiagnose this as a connection leak in application code. The sidecar pattern is an anti-pattern for high-density microservices because it multiplies connection counts by pod count. The robust solution uses a centralized connection pooler \(PgBouncer\) as a Kubernetes deployment with fewer replicas \(e.g., 2-3 instances\) that maintain a constrained connection pool to Cloud SQL \(e.g., 20 total connections\), while applications connect to PgBouncer with short-lived connections. Alternatively, using the Cloud SQL Connector libraries \(Go, Java, Python\) with explicit connection pooling configuration avoids the sidecar overhead entirely.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T01:08:11.631260+00:00— report_created — created