One connection has several acceptance gates
An application connecting to Cloud SQL must reach the intended instance, satisfy the access requirements of its connection method and authenticate to the database. After that, its connection pool must remain healthy under real workload. Treating every failure as 'the database is unavailable' sends responders toward the wrong layer.
Google's connectivity guidance distinguishes connecting, authorizing and authenticating. A timeout differs from a database access-denied response. A connector can also fail before a database session exists. Record the exact error, instance identity and application runtime before deciding whether the incident belongs to networking, identity or database operations.
Build a documented initial connection
- Choose the approved public or private connection design and document its network dependencies. Do not assume that a connector automatically creates missing network reachability.
- Identify the application runtime principal, the selected connector or client, and the database authentication method. Keep the database user and its permissions separate from cloud resource administration.
- Configure a bounded connection pool, request timeouts and secret handling. Rehearse instance maintenance and application restart behavior with representative concurrent requests.
A private connection that works from one VM is not proof that another network can use it. Likewise, an administrator's database user does not verify the permissions used by the production application.
Illustrative incident: capacity looks healthy but requests wait
After an application rollout, database sessions remain open longer than before. New requests wait for a free pool connection and eventually time out. The instance is reachable and existing queries still execute. This illustrative scenario requires examining application connection ownership; adding network firewall rules cannot free a leaked pool connection.
Trace a failed request across the boundaries
Capture a sanitized request correlation ID and compare application, connector and database events for the same period. Review how the application obtains and releases a connection, including exceptional paths. Avoid placing a connection string with a password into a ticket or process listing.
| Observation | First evidence | What it separates |
|---|---|---|
| TCP path does not complete | Intended route and source network | Reachability from credentials |
| Connector reports permission failure | Actual runtime principal and permission | Cloud identity from SQL user |
| SQL user is rejected | Database authentication configuration | Authentication from transport |
| Pool acquisition waits while sessions persist | Pool counters and connection lifecycle | Client resource ownership from instance outage |
Use the provider's supported connectivity diagnostics for the selected architecture. A low-level connection test should be scoped to the instance and port; it must not become a broad network scan or an excuse to allow every source.
Make a targeted correction
For the illustrative pool issue, repair connection cleanup and review transaction duration. Size the pool against application replicas and database capacity together. If the evidence instead identifies a permission fault, have the appropriate owner change that specific entitlement. Preserve configuration values needed for reversal and avoid combining a pool change with a major database upgrade.
Verify the original failing business operation under realistic concurrency. Confirm that pool usage returns toward its expected baseline after requests complete. Rehearse a process restart and a controlled database disconnect outside production. A single successful SQL query from a command-line administrator is only a partial test.
Operate the application-database relationship
Measure pool acquisition delay, connection errors and business transaction success. An illustrative internal objective might require 99% of accepted requests to obtain a connection within the application's agreed latency budget during a controlled load test. This is a sample engineering target, not a Cloud SQL SLA or a measured outcome.
The SOP should retain connection architecture, runtime principal, authentication method, pool owner, observed failure and rollback trigger. Escalate changes that affect network reachability or database capacity to both application and infrastructure owners. Review the total connection budget whenever replica count changes.
See database administration for related operating scope.
Technical reference
Google Cloud: debug Cloud SQL for MySQL connectivity. Reviewed 19 October 2026; validate behavior for the connection method and client version in use.