What is Google Cloud SQL?
Google Cloud SQL is an easy-to-use service that delivers fully managed MySQL databases.

What are the benefits of using Google Cloud SQL?
Cloud SQL lets you hand off to Google the mundane, but necessary and often time consuming tasks — like applying patches and updates, managing backups and configuring replications — so you can put your focus on building great applications. And because we use standard MySQL, it’s easy to connect from just about any application, anywhere.

Which versions of MySQL are available with Google Cloud SQL? How are updates managed?
Second Generation instances support MySQL 5.6 and 5.7; First Generation instances support MySQL 5.5 & MySQL 5.6. Supported versions are updated to the current generally available release (see http://www.mysql.com/downloads/). Minor version updates are deployed as they are released, with no further action required on your part. For more information about updates, see What kind of maintenance shutdowns should I expect with my instance?.

To see the current version of your instance, go to the Google Cloud Platform Console, select your instance and view the Properties. Or, you can execute SHOW VARIABLES LIKE "%version%"; from a SQL prompt, and look for the value of the version variable.

Does Google Cloud SQL support all the features of MySQL?
Google Cloud SQL supports most common features of MySQL. For a list of all differences between standard MySQL and the functionality Cloud SQL provides, see Differences between Google Cloud SQL and standard MySQL functionality.
Are there any size or QPS limits?
There are no queries per second (QPS) limits for Google Cloud SQL instances. However, there are connection, size, and App Engine specific limits in place.

Cloud SQL instances limits

Limit First Generation instances Second Generation instances Notes
Concurrent connections Determined by tier 4,000
Enqueued connection requests 100 N/A First Generation instances only. Incoming connection requests are briefly queued before the connection is established. The queue can accept only 100 incoming connection requests.
Storage size 250 GB Determined by machine type 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.

The connection limits are in place to protect against accidents and abuse. For questions about increasing these values, contact the cloud-sql@google.com team.

Google App Engine Limits

Requests from Google App Engine applications to Google 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 24 hours.
  • Offline requests like cron tasks have a time limit of 10 minutes.
  • Requests to Google 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 or using Standard-compatible APIs cannot have more than 12 concurrent connections to a Google Cloud SQL instance.

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

Learn more about the App Engine flexible environment.

How can I be notified when there are any changes to Google Cloud SQL?
You can sign up for the google-cloud-sql-announce forum where we post announcements and news about Google Cloud SQL.

How do I report a bug, request a feature, or ask a question?
You can report bugs and request a feature on our project page. You can ask a question in Stack Overflow. For other support options, see the Google Cloud SQL Support page.

What are the known issues?
See the known issues list on our project page.

Getting Started

What is the best MySQL tool to use for managing my instance?
There are a variety of MySQL tools available for Google Cloud SQL. For executing simple statements, you can use the MySQL Command-Line Tool. For executing more complicated tasks or to use a richer database development environment, you can try Toad for MySQL or MySQL Workbench. For more information, see Admin and Reporting Tools.

What storage engine should I use?
For Second Generation instances, InnoDB is the only storage engine supported. For First Generation instances, the InnoDB storage engine is recommended, because it provides stronger data consistency guarantees.

If you have a mysqldump file where all your tables are in MyISAM format, you can convert them to InnoDB format by piping the file through a sed script:

mysqldump --databases [DATABASE_NAME] \
--hex-blob --default-character-set=utf8 | sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' > [DATABASE_FILE].sql

Warning: You should not do this if your mysqldump file contains the mysql schema. Those files must remain in MyISAM.

I've just created a new instance with no data but the dashboard shows I have already used some disk space. Why?
The InnoDB storage engine creates initial log and data files when your instance is created.

Why is my First Generation instance sometimes slow to respond?
In order to minimize the amount you are charged for instances on per-use billing plans, by default your instance becomes passive if it is not accessed for 15 minutes. The next time it is accessed there will be a short delay while it is activated. You can change this behavior by configuring the activation policy of the instance. Learn more.

Which activation policy should I use?
If you are using a Second Generation instance, or a First Generation instance with the Package billing plan, you should set your activation policy to ALWAYS, because there is no cost benefit to turning off your instance when it is not being used.

If you are using a First Generation instance with the Per-Use billing plan, you can reduce your costs by setting your activation policy to ON DEMAND. This setting causes your instance to automatically shut itself off after 15 minutes of inactivity, so you are not incurring charges when the instance is not in use.

When your instance has an activation policy of ON DEMAND, there is a small delay for any access request that comes in when the instance is off, because the instance must start up before servicing the request.

Data Storage and Replication

Where is my data stored?
Data for a Google Cloud SQL instance is stored in zones in the United States, European Union, or Asia depending on the location that you select when creating the instance. Data at rest in the United States or European Union regions is kept within its region. This guarantee cannot be made for instances created in Asia.

What is a zone?
A zone is an independent entity in a specific geographical location where you can run your resources. For example, a zone named us-central1-a indicates a location in the central United States.
By default, data in Cloud SQL First Generation is replicated, and the service is distributed across multiple zones to provide fault tolerance for zone outages. For Cloud SQL Second Generation, fault tolerance across zones can be configured by confinguring the instance for high availability (adding a failover replica). Failover replicas are strongly recommended for all production database instances.
For more information about zones, see Zone Resources in the Google Compute Engine documentation.

What are the limits on storage?
First Generation instances: The size of all instances is limited to 250GB by default. Maximum storage size is determined by the time it takes to restore an instance from backup in case of a problem; we cannot guarantee to restore instances larger than 250GB within 24 hours (smaller instances restore faster). Customers with a Silver or higher Google Cloud support package can request an increase up to 500GB for individual instances.

Second Generation instances: You can configure the storage capacity of your instance from 10 GB to 10,240 GB (3062 GB for shared-core machine types). Instance capacity cannot be decreased, it can only be increased. You can also configure your instance to automatically increase its storage capacity when space is running low. Learn more.

How is my data replicated?
Cloud SQL First Generation: When you create a First Generation instance, your data is replicated in two zones within the US, EU, or Asia locations using asynchronous replication.

Cloud SQL Second Generation: Second Generation read replicas use asynchronous replication. Second Generation failover replicas use semisynchronous replication.

How does Google Cloud SQL failover work?
Cloud SQL First Generation: All Cloud SQL data on First Generationinstances is replicated in multiple zones. In the unlikely event of a zone outage, instances fail over to another, available, zone automatically. Failover is designed to be transparent to your applications, so that after failover, an instance has the same instance name, IP address, and firewall rules. During the failover there will be a few minutes of downtime while your instance starts up in the new zone.

In a failover event, existing connections to instances are broken. You can test how your application responds to a failover by restarting your instance. For recommendations on managing connections that can help in failover events, see the FAQ entry How should I manage connections?

Cloud SQL Second Generation: You have the choice whether to have your data replicated between zones or not. You can save money by not replicating your data, but if you need availability for your data, you should configure your instance for high availability. Second Generation instances configured for high availability have the same failover capability as First Generation instances. For more information, see Overview of the High Availability Configuration.

Is my data encrypted?
Yes. Cloud SQL customer data is encrypted when on Google’s internal networks and when stored in database tables, temporary files, and backups.

External connections can be encrypted by using SSL, or by using the Cloud SQL Proxy.

How is encryption managed?
Your data is encrypted using the 128-bit Advanced Encryption Standard (AES-128), or better, with symmetric keys: that is, the same key is used to encrypt the data when it is stored, and to decrypt it when it is used. These data keys are themselves encrypted using a master key, stored in a secure keystore, and changed regularly.

Is my data encrypted when it’s on Google’s internal network?
What kind of read replicas can I create?
You can configure:
  • Cloud SQL instances that replicate from a Cloud SQL master instance.
  • Cloud SQL First Generation instances that replicate from an external master instance.
  • External MySQL instances that replicate from a Cloud SQL master instance.

Note that external read replica instances must:

  • Be able to connect to the Cloud SQL master instance with the MySQL wire protocol.
  • Support row-based replication.
  • Be the same (or later) version of the Cloud SQL instance being replicated.

For more information about read replicas, including use cases for each type, see Replication Options.

How can I tell if an instance is a read replica?
You can use the Google Cloud Platform Console to see all of your Cloud SQL instances, and whether an instance is a master or read replica instance. You can use the Cloud SDK to check whether an instance is a master or read replica.

Backups and Point-in-Time Recovery

How do I recover an instance?
To restore to a backup you can use the Google Cloud Platform Console or the Cloud SQL command-line tool. For more details, see Restoring an Instance.

To restore a First Generation instance to a specific point in time, you use the Cloud SQL command-line tool. For more information, see Performing a Point-in-Time Recovery.

How much do backups cost?
First Generation instances: Storage of the most recent 7 backups is included in the cost of your instance. Binary log space counts toward the storage used in an instance.
Second Generation instances: The most recent 7 backups are retained. They are charged at $0.08 per GB/month. Binary log space uses and is charged as data storage.
For more information about instance storage pricing and instance rates, see Pricing.

How do I enable point-in-time recovery?
Point-in-time recovery is not enabled by default. You must enable automated backups and binary logging for an instance to use point-in-time recovery. Point-in-time recovery is not supported for Second Generation instances. For more information, see Backup and Recovery.

How does point-in-time recovery impact performance?
Point-in-time recovery requires that you enable binary logging. This means that every update to your database is written to an independent log, which involves a small reduction in write performance. Reads are unaffected. The impact on performance is greater for instances that use synchronous replication, so we recommend that binary logging is used together with asynchronous replication.

Managing Your Instances

Can I make my database larger or smaller by changing between tiers?
First Generation instances: You can change the tier of your database at any point. Note that this will force your instance to restart, which takes a few seconds.
Second Generation instances: You can increase the amount of storage available to your instance at any time without incurring downtime. You cannot decrease the size of the storage of your instance.

Do I need to use the Google Cloud Platform Console to manage Google Cloud SQL?
No. All management tasks that can be done via the console can also be done programmatically via the Cloud SQL API.

How large a database can I use with Google Cloud SQL?
First Generation instances: Your database instance can be no larger than 500GB.
Second Generation instances: Your database instance can be up to 10,240 GB (3062 GB for shared-core machine types).

How can I reclaim the space from a dropped table?
When you drop a table from a database and then check the Google Cloud Platform Console, you might see that the space freed by dropping the tables is not reflected in the reported Storage Used of the instance. Instances running MySQL 5.5 have the innodb_file_per_table flag set to OFF by default; InnoDB never shrinks its default tablespace. To reclaim space for this configuration, create a new instance from the smaller database, or change the value of the innodb_file_per_table flag to ON. For information about changing MySQL flags, see Configuring MySQL Flags.

How can I track changes to data?
To track changes to data, enable binary logging for your instance. Tracking changes to data can help you recover from accidental data loss. In the event of accidental data loss such as from a DROP DATABASE command, you can restore up to the binary log coordinates just before the data loss event. For more information, see point-in-time recovery.

What kind of maintenance shutdowns should I expect with my instance?
First Generation instances: We periodically restart Cloud SQL instances to perform upgrades, migrate between zones, and perform other infrastructure work. Since your data is replicated in multiple locations, the interruption to your instances is typically a few seconds to a few minutes. First Generation instances configured to follow an App Engine application may also be restarted in a new location in order to minimize the latency from that application as it moves. This may involve a short period of increased latency, and typically a few seconds of unavailability.

Second Generation instances: With Second Generation instance, you can select a maintenance window for your instance, so you can control when maintenance restarts occur.

We recommend that you design your applications to deal with situations when your instance is not accessible for short periods of time, such as in a maintenance shutdown. You can test the behavior of your application to a maintenance shutdown by restarting your instance, which has the same effect. In general, we recommend that you use only short-lived connections as well as use exponential back-off for retrying rejected connections. For more guidance see How should I manage connections?

Note that the amount of time mysqld has to shutdown is capped to 1 minute. If the shutdown does not complete in that time, the mysqld process is forcefully terminated. This will incur a longer startup time because the InnoDB storage engine does a crash-recovery before the server is ready to start serving queries. The time for a crash-recovery to complete depends on the size of the database; larger databases require more time for recovery.

Can I import or export a specific database?
Yes, you can import or export a specific database or all databases on an instance. For more information, see Overview of Importing and Exporting Data.

Can I import or export a CSV file?
Yes, you can import or export a CSV file. For more information, see Creating mysqldump and csv Files.

Do I need a Google Cloud Storage account to import or export data to an instance?
You can import and export databases to instances using mysqldump files and standard tools, such as MySQL Client, that do not require a Google Cloud Storage account. Note that some options of the mysqldump tool are not supported by Google Cloud SQL. For more information, see MySQL features supported by Google Cloud SQL.

Cloud SQL supports importing and exporting databases (compressed or uncompressed mysqldump files) and CSV files using a Google Cloud Storage bucket. To import or export using a Google Cloud Storage bucket, you need to either sign up for a Cloud Platform account and create a bucket, or have access to a Google Cloud Storage bucket in another account. For more information, see Overview of Importing and Exporting Data.

What does ERROR_RDBMS mean on an import operation?
This error occurs if MySQL returns an error during a data import operation. Common causes include invalid syntax, using a database or table that has not been defined, and attempting to run MySQL statements that require the SUPER privilege.

If I delete my instance, can I reuse the instance name?
Yes, but not right away. The instance name is unavailable for up to a week before it can be reused.

A 'gserviceaccount' is shown in the team members in the console. What is it?
This account was created automatically and is used by Google to manage your Cloud SQL instance, but has no effect on your project. (For example, it does not matter if you alter the permissions on this account.)

What is the cloudsqladmin database user?
Every Google Cloud SQL instance includes a database user called cloudsqladmin. You may notice this user if you do a SHOW GRANTS FOR cloudsqladmin@localhost. On some instances this will also show up in the mysql.user table. This user account is used by automated processes that need to access the data in your instance (for example, backing up your instance or performing an import or export).

How can I use GRANT ALL?
Google Cloud SQL does not support SUPER privileges, which means that GRANT ALL PRIVILEGES statements will not work. As an alternative, you can use GRANT ALL ON `%`.*.

How can I access transaction logs for my instances?
If you enable binary logging for your instance (see Enabling binary logging) and configure an IP address for your instance (see Configuring access for IP connections), then you can use the standard MySQL mysqlbinlog utility to examine the transaction logs for the instance.

Pricing and Billing

How can I try out Google Cloud SQL?
First Generation instances: The D0 tier and per-use billing means that you can try out the service for just $0.025 per hour, charged by the minute, and you only pay this while the instance is being used.
Second Generation instances: The smallest Second Generation instance is db-f1-micro. You can use it to try out the service for just $0.0105/hour, charged by the minute (sustained usage price).

Which pricing plan should I use? Per-use or package?
Per-use and package pricing options are applicable only for First Generation instances. As a rule of thumb. it is more economical to opt for the package plan if your instance is used for more than 450 hours each month.
See Pricing for details of the pricing plans.

Can I change between plans?
Per-use and package pricing options are applicable only for First Generation instances. You can change the billing plan for your instance up to 3 times per month. The plan in effect at the end of the day (US Pacific Time) is the one used to calculate the charge for your instance. You can change your plan as many times as you like in a single day, and it counts as one of your three monthly changes.

You can change the billing plan for a First Generation instance by editing its settings. Do this by going to the Google Cloud Platform Console, selecting the project that contains the instance, and then selecting Google Cloud SQL. From the list of instances, select one and edit its settings, which includes billing settings.

How many instances can I create in a project?
You can create up to 10 instances per project. Deleted instances do not count toward the 10-instance limit. You can request that the instance limit be raised for a project by contacting the cloud-sql@google.com team.

What size database instance do I need? How much RAM?
For First Generation instances, if you already know approximately how much data you will have then the fixed package sizes are a good guide to a suitable instance size. In general, you can increase the performance of your database by choosing a larger instance with more RAM and CPU. This increases the performance of many queries that involve large amounts of computation, such as those involving joins, ORDER BYs, or GROUPing, though the performance of updates affecting single rows will not be much affected. For more information about instance sizes and pricing, see the pricing page.

How is use of my instance calculated?
First Generation instances: If your instance is using the per-use billing plan, you are charged per minute for the time that your instance is on.

If it is using an activation policy of ON_DEMAND (the default value), your instance is started whenever you access it (whether from a SQL prompt, an external application, or from an App Engine application), and remains up for 15 minutes after the completion of the last access. After this time, the instance is shut down. You are not charged for the time your instance is off.

Note that an instance stays up as long as there are clients connected to it. This includes idle connections. You can list the connections to an instance using the MySQL client and executing the SHOW PROCESSLIST command. You can then use the KILL command to kill connections. You can also restart the instance to kill all the connections.

Instances using the package billing plan with an activation policy of ON_DEMAND remain on for 12 hours after the last access.

You can change the activation behavior of an instance by modifying its activation policy. Learn more.

Second Generation instances: You are charged per minute for the time that your instance is on.

How is storage calculated?
First Generation instances: Storage is calculated based on the amount of file space used by your instance. Storage is charged by the GB, and measured every minute so your charges closely follow your usage. Storage charges are incurred whether the instance is on or off. Storage for backups created using the scheduled backup service is not charged.
Second Generation instances: Storage is calculated based on the amount of storage you have provisioned for your instance. Storage for backups is charged by how much space your backups are using. Storage is charged whether your instance is on or off.

How can I see how much I will be charged?
The Billing tab of the Google Cloud Platform Console shows you how much charge your instances have gathered since the last bill was issued.

I have not been using my First Generation instance recently--why have I been charged even though I am on the "per-use" plan?
Check to see if you have enabled scheduled backups for the instance. Google Cloud SQL takes a backup of an instance only if the instance's data has changed since the last scheduled backup. Whenever a scheduled backup occurs, the instance is activated for the duration of the backup, incurring "per-use" fees.

What happens when my instance reaches the allowed size?
First Generation instances: If your instance reaches the maximum storage amount allowed by the plan you have chosen, future writes to the database are disallowed until you delete data to reduce the size.
Second Generation instances: If your instance reaches the provisioned storage size, future writes to the database are disallowed until you increase the storage size. Increasing the storage size does not require an instance restart or downtime.

Why is my instance suspended?
This is probably due to an issue with your Google Cloud Platform account. You can determine your billing status by filing a Billing Support Request. Note that suspended Second Generation instances are deleted after 90 days.

Why was my instance deleted?
Second Generation instances that are suspended for 90 days are deleted. This applies to instances with a state of SUSPENDED. Instances that are stopped, with a state of RUNNABLE, are not deleted.

How can I cancel my Google Cloud SQL account?
You can deactivate Google Cloud SQL for a project by visiting the Google Cloud Platform Console, selecting the project, selecting the API service to open the API Dashboard. Find the Google Cloud SQL API and click Disable for that API.

How do I disable billing?
You can disable billing by clicking Disable billing in the Google Cloud Platform Console Billing & settings pane for a project. If you disable billing, you also disable the Google Cloud SQL service. Make sure you really want to disable the Google Cloud SQL service before you disable billing.

After you disable billing, you will receive one last bill for charges that occurred between the beginning of the billing cycle and when you cancelled.

Using Google Cloud SQL with App Engine

Can I connect from App Engine to a Cloud SQL Second Generation instance?
Yes. You can connect from an App Engine application to a Cloud SQL Second Generation instance, whether the application is running in the standard or the flexible environment. For more information, see Connecting from Google App Engine.

Can my App Engine in the US access my Google Cloud SQL instance in the EU (and vice versa)?
If you are connecting to a First Generation instance, your App Engine application must be in the same region as your Cloud SQLinstance, and it must be running in the standard environment.

If you are connecting to a Second Generation instance, your App Engine does not need to be in the same region, and it can be running in either the standard or the flexible environment.

Should I use Google Cloud SQL or the App Engine Datastore?
This depends on the requirements of the application. Datastore provides NoSQL key-value storage that is highly scalable, but does not support the complex queries offered by a SQL database. Cloud SQL supports complex queries and ACID transactions, but this means the database acts as a 'fixed pipe' and performance is less scalable. Many applications use both types of storage.

Do I need to install a local version of MySQL to use the App Engine Development Server?
No. You can configure App Engine to use either Cloud SQL or a locally installed version MySQL when running on the development server.

What languages can I use to access my instance?
Google App Engine supports several languages that you can use to connect to your instances. For more information, see Connecting from Google App Engine.

If you are not using Google App Engine, you can use any language that has an associated MySQL connector or API. For a list of supported languages, see the Connectors and APIs chapter in the MySQL Reference Manual.

Can I use Django with Google Cloud SQL?
Yes, Google Cloud SQL is compatible with Django! See the Django Support documentation for details.

Which placeholders can I use in my Python query string?
Python users can only use the %s format code in parameter substitution. Therefore, the following statement is invalid: cursor.execute('INSERT INTO entries (guestAge) VALUES (%d)', (age)).

How should I manage connections?
How to best manage your database connections depends on your use case but, in general, we recommend using connection pooling. Connection pooling will protect the database server from large numbers of new connections created too rapidly, which can impact performance.

In cloud-hosted environments, you should manage your database connections differently than managing them in a conventional, external server environment. We recommend that you design your applications to handle occasional connection failures by implementing an error handling strategy like exponential backoff. For an example, see Exponential backoff in the Google Cloud Storage documentation.

To learn more about instance connection limits, see the FAQ Are there any size or QPS limits?

What does a SQLException with message of "Invalid connection ID" mean?
It means that the connection is no longer open on the server and should be discarded by the client.  You do not need to call 'close' on these connections; they are already closed.

Can I access my Google Cloud SQL instance programmatically outside of App Engine?
Yes. You can access Google Cloud SQL instances programmatically from external applications using any language that has an associated MySQL connector or API. You can also connect using JDBC, including writing Apps Script scripts to access your Google Cloud SQL databases. See Connecting from External Applications.

Send feedback about...

Cloud SQL Documentation