Count the whole application
Connection pools are usually configured per process or application instance. When an application scales out, its total possible database connections scale too.
Start with an upper-bound estimate:
maximum application connections
= maximum instances
× worker processes per instance
× pool size per process
Then add migrations, background jobs, monitoring, and administration. The result needs headroom within the database's supported operating limits.
Pools reduce churn, not every problem
A pool reuses connections and can control how many operations reach the database concurrently. An oversized pool can still overload the database, while an undersized pool may create long waits in the application.
Measure both connection acquisition time and query execution time.
Separate transport from identity
A secure connection path and permission to authenticate are related but different concerns. Google Cloud connectors and the Cloud SQL Auth Proxy help with particular connection and authorization flows, but the complete setup still needs appropriate IAM, database credentials or supported IAM authentication, and network reachability.
Choose guidance for your exact engine and runtime.
Handle stale connections
A restart or failover can invalidate established connections. Configure bounded retries and timeouts, and confirm that failed connections are discarded.
Retrying a write is not automatically safe. The application needs a strategy for determining whether the previous attempt committed.
Test scaling behavior
Load-test the application while increasing the number of instances. Watch active connections, waiting requests, transaction duration, and database utilization.
A useful pool size is an operating parameter measured under load, not a number copied from a tutorial.
Before deployment
Document the engine, instance configuration, network path, authentication method, pool owner, and maximum scale. Check current product limits rather than embedding one supposedly universal connection count.