Diagnosing Issues with Cloud SQL Instances

This page contains a list of the most frequent issues you might run into when working with Google Cloud SQL instances as well as steps you can take to address them. If the information here does not solve your issue, see the Support Overview for getting further help.

Viewing logs

To see information about recent operations, you can view the Cloud SQL instance operation logs or the PostgreSQL error logs.

Connection issues

Verify that your certificates have not expired

If your instance is configured to use SSL, go to the Cloud SQL Instances page in the GCP Console and open the instance. Open its SSL page and make sure that your server certificate is valid. If it has expired, you must refresh it and recreate your client certificates. Learn more.

Verify that you are authorized to connect

If your connections are failing, check that you are authorized to connect:

  • If you are having trouble connecting using an IP address, for example, you are connecting from your on-premises environment with the psql client, then make sure that the IP address you are connecting from is authorized to connect to the Cloud SQL instance. Here's your current IP address.
  • Try the gcloud sql connect to connect to your instance. This command authorizes your IP address for a short period of time. You can run this in an environment with Cloud SDK and psql client installed. You can also run this command in Google Cloud Shell, which is available in the Google Cloud Platform Console and has Cloud SDK and the psql client pre-installed. Cloud Shell provides a Compute Engine instance that you can use to connect to Cloud SQL.
  • Temporarily allow all IP addresses to connect to an instance by authorizing This confirms that your client can connect.

Understand connection limits

There are no QPS limits for Google Cloud SQL instances. However, there are connection, size, and App Engine specific limits in place.

Cloud SQL for MySQL Second Generation connection limits

Machine type Maximum concurrent connections
db-f1-micro 250
db-g1-small 1,000
All other machine types 4,000

Cloud SQL for PostgreSQL connection limits

Memory size, in GiB Maximum concurrent connections*
0.6 (db-f1-micro) 25
1.7 (db-g1-small) 50
3.75 up to 6 100
6 up to 7.5 150
7.5 up to 15 200
15 up to 30 250
30 up to 60 300
60 up to 120 400
120 and above 500

*Cloud SQL for PostgreSQL reserves up to six of these connections for internal operations.

Cloud SQL for MySQL First Generation connection limits

Incoming connection requests are briefly queued before the connection is established. The queue can accept only 100 incoming connection requests.

Tier Maximum concurrent connections
D0 - D2 250
D4 500
D8 1,000
D16 2,000
D32 4,000

Cloud SQL storage limits

MySQL First Generation instances MySQL Second Generation instances PostgreSQL instances Notes
250 GB Up to 10,230 GB, depending on machine type Up to 10,230 GB, depending on whether the instance has dedicated or shared vCPUs. It is possible to increase individual First Generation instance limits up to 500 GB for customers with a Silver or higher Google Cloud support package.

App Engine Limits

Requests from App Engine applications to Cloud SQL are subject to the following time and connection limits:

  • For apps running in the Google App Engine standard environment, all database requests must finish within the HTTP request timer, around 60 seconds. For apps running in the flexible environment, all database requests must finish within 60 minutes.
  • Offline requests like cron tasks have a time limit of 10 minutes.
  • Requests to Cloud SQL have limitations based on the scaling type of the App Engine module and how long an instance can remain in memory (residence).
  • Each App Engine instance running in a standard environment cannot have more than 60 concurrent connections to a Cloud SQL instance.

App Engine applications are also subject to additional App Engine quotas and limits as discussed on the Quotas page.

To learn more about managing connections, see the FAQ How should I manage connections?.

Connections from Compute Engine

If you expect that connections between your Compute Engine instance and your Cloud SQL instance will include long-lived unused connections, then you should be aware that connections with a Compute Engine instance time out after 10 minutes of inactivity. For more information, see Networking and Firewalls in the Google Compute Engine documentation.

To keep long-lived unused connections alive, you can set the TCP keepalive. The following commands set the TCP keepalive value to one minute and make the configuration permanent across instance reboots.

# Display the current tcp_keepalive_time value.
cat /proc/sys/net/ipv4/tcp_keepalive_time

# Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.
echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf

# Apply the change.
sudo /sbin/sysctl --load=/etc/sysctl.conf

# Display the tcp_keepalive_time value to verify the change was applied.
cat /proc/sys/net/ipv4/tcp_keepalive_time

Instance issues

Disk space

If your instance reaches the maximum storage amount allowed, writes to the database fail. If you delete data, for example, by dropping a table, the space is usually freed, but it is not reflected in the reported Storage Used of the instance. You can run the VACUUM FULL command to recover unused space; note that write operations are blocked while the vacuum command is running. Learn more.

Suspended state

There are a number of reasons why Google Cloud SQL may suspend an instance, including:

  • Billing issues

    For example, if the credit card for the project's billing account has expired, the instance may be suspended. You can check the billing information for a project by going to the Google Cloud Platform Console billing page, selecting the project, and viewing the billing account information used for the project.

  • Legal issues

    For example, a violation of the Google Cloud Platform Acceptable Use Policy may cause the instance to be suspended. For more information, see "Suspensions and Removals" in the Google Cloud Platform Terms of Service.

  • Operational issues

    For example, if an instance is stuck in a crash loop, i.e., it crashes while starting or just after starting, Google Cloud SQL may suspend it.

While an instance is suspended, you can continue to view information about it or you can delete it, if the suspension was triggered by billing issues.

Cloud SQL users with Platinum, Gold, or Silver support packages can contact our support team directly about suspended instances. All users can use the guidance above along with the google-cloud-sql forum.


Keep a reasonable number of database schemas and tables

Database schemas and tables consume system resources. A very large number can affect instance performance.

General performance tips

Make sure that your instance is not constrained on memory or CPU. For performance-intensive workloads, your instance should have at least 60 GB of memory.

For slow database inserts, updates, or deletes, check the locations of the writer and database; sending data a long distance introduces latency.

For slow database selects, consider the following:

  • Caching is extremely important for read performance. Check the various blks_hit / (blks_hit + blks_read) ratios from the PostgreSQL Statistics Collector. Ideally, the ratio should be above 99%. If this is not the case, consider increasing the size of your instance's RAM.
  • If your workload consists of CPU intensive queries (sorting, regexes, other complex functions), your instance might be throttled; add vCPUs.
  • Check the location of the reader and database - latency will affect read performance even more than write performance.
  • Investigate non-Cloud SQL specific performance improvements, such as adding appropriate indexing, reducing data scanned, and avoiding extra round trips.
If you observe poor performance executing queries, use EXPLAIN to identify where to add indexes to tables to improve query performance. For example, make sure every field that you use as a JOIN key has an index on both tables.

Send feedback about...

Cloud SQL for PostgreSQL