Member-only story
Cloud Run Can Scale Past Your Database Connection Budget
Count worker processes, pool overflow and rollout overlap before raising the instance limit.
Say you’re preparing a Cloud Run API for a traffic spike. The service has a maximum of 20 instances. Its PostgreSQL pool is configured with four connections. Your Cloud SQL instance has room for considerably more than 80, so the change looks comfortable.
Then someone checks the container’s startup command: two worker processes. Each process creates its own pool. Another setting permits two overflow connections per pool.
The potential demand is now 240 connections, before counting the reporting service, a migration job or an administrator’s session. Nothing about the original multiplication was difficult. It just left out two multipliers.
This is a hypothetical configuration, but the underlying problem is current. Nic Vannetti’s 6 October discussion and Madhav Bhasin’s article updated on 1 September both examine how small application pools become a larger database demand when services scale.
For a Cloud Run service backed by Cloud SQL for PostgreSQL, a useful next step is a connection budget that includes processes, overflow and deployment conditions. The small Python worksheet below makes those assumptions visible. It calculates capacity demand; it doesn’t…
