Cloud SQL
Cloud SQL instances are simple managed relational cloud database servers that can be created via the API, CLI and Control Panel.
Engines and Versions
Both MySQL and PostgreSQL database engines are available.
When creating a new Cloud SQL Instance, the current minor version of the chosen engine is used as the starting point and future point releases are installed during the weekly maintenance window as they become available.
MySQL
The table below shows the major and minor MySQL versions available.
| Major Version | Current Minor Version | End of Life |
|---|---|---|
| 8.0 | 8.0.34 | Apr 2026 |
| 5.7 | 5.7.43 | Oct 2023 (deprecated) |
MySQL snapshot compatibility
Snapshots of MySQL instances are compatible between point releases but not between minor versions. So you cannot snapshot a MySQL 5.6 instance and create a 5.7 instance from the snapshot. To upgrade minor versions, create a new instance and use the standard mysql tools to take and reload a database dump.
Snapshotting MyISAM tables
The snapshot process depends on crash recoverable storage engines, such as InnoDB. MySQL’s MyISAM engine is not a crash recoverable storage engine so snapshots of MyISAM tables may result in incomplete or corrupt data.
If you need to use MyISAM tables, then you can minimise the risk of corrupted tables in snapshots by flushing and locking them prior to creating a snapshot. They only need to be locked for a few seconds at the start of the snapshot, and not during the copy process.
PostgreSQL
The table below shows the major and minor PostgreSQL versions available.
| Major Version | Current Minor Version | End of Life (final release) |
|---|---|---|
| 17 | 17.0 | 8 Nov 2029 |
| 16 | 16.4 | 9 Nov 2028 |
| 15 | 15.8 | 11 Nov 2027 |
| 14 | 14.13 | 12 Nov 2026 |
| 13 | 13.16 | 13 Nov 2025 |
| 12 | 12.20 | 14 Nov 2024 |
| 11 | 11.22 | 9 Nov 2023 (deprecated) |
| 10 | 10.23 | 10 Nov 2022 (deprecated) |
| 9.6 | 9.6.24 | 11 Nov 2021 (deprecated) |
| 9.5 | 9.5.25 | 11 Feb 2021 (deprecated) |
For more information, see the PostgreSQL versioning policy documentation.
PostgreSQL extensions
The following PostgreSQL extensions are available for use and can be activated
using the standard CREATE EXTENSION command.
| address_standardizer | 3.0.0 | Used to parse an address into constituent elements |
| address_standardizer_data_us | 3.0.0 | Address Standardizer US dataset example |
| adminpack | 2.0 | administrative functions for PostgreSQL |
| amcheck | 1.1 | functions for verifying relation integrity |
| autoinc | 1.0 | functions for autoincrementing fields |
| bloom | 1.0 | bloom access method - signature file based index |
| btree_gin | 1.3 | support for indexing common datatypes in GIN |
| btree_gist | 1.5 | support for indexing common datatypes in GiST |
| citext | 1.5 | data type for case-insensitive character strings |
| cube | 1.4 | data type for multidimensional cubes |
| dblink | 1.2 | connect to other PostgreSQL databases from within a database |
| dict_int | 1.0 | text search dictionary template for integers |
| dict_xsyn | 1.0 | text search dictionary template for extended synonym processing |
| earthdistance | 1.1 | calculate great-circle distances on the surface of the Earth |
| file_fdw | 1.0 | foreign-data wrapper for flat file access |
| fuzzystrmatch | 1.1 | determine similarities and distance between strings |
| hstore | 1.5 | data type for storing sets of (key, value) pairs |
| hstore_plperl | 1.0 | transform between hstore and plperl |
| hstore_plperlu | 1.0 | transform between hstore and plperlu |
| hstore_plpython2u | 1.0 | transform between hstore and plpython2u |
| hstore_plpythonu | 1.0 | transform between hstore and plpythonu |
| insert_username | 1.0 | functions for tracking who changed a table |
| intagg | 1.1 | integer aggregator and enumerator (obsolete) |
| intarray | 1.2 | functions, operators, and index support for 1-D arrays of integers |
| isn | 1.2 | data types for international product numbering standards |
| jsonb_plperl | 1.0 | transform between jsonb and plperl |
| jsonb_plperlu | 1.0 | transform between jsonb and plperlu |
| jsonb_plpython2u | 1.0 | transform between jsonb and plpython2u |
| jsonb_plpythonu | 1.0 | transform between jsonb and plpythonu |
| lo | 1.1 | Large Object maintenance |
| ltree | 1.1 | data type for hierarchical tree-like structures |
| ltree_plpython2u | 1.0 | transform between ltree and plpython2u |
| ltree_plpythonu | 1.0 | transform between ltree and plpythonu |
| moddatetime | 1.0 | functions for tracking last modification time |
| pageinspect | 1.7 | inspect the contents of database pages at a low level |
| pg_buffercache | 1.3 | examine the shared buffer cache |
| pg_freespacemap | 1.2 | examine the free space map (FSM) |
| pg_prewarm | 1.2 | prewarm relation data |
| pg_stat_statements | 1.6 | track execution statistics of all SQL statements executed |
| pg_trgm | 1.4 | text similarity measurement and index searching based on trigrams |
| pg_visibility | 1.2 | examine the visibility map (VM) and page-level visibility info |
| pgcrypto | 1.3 | cryptographic functions |
| pgrowlocks | 1.2 | show row-level locking information |
| pgstattuple | 1.5 | show tuple-level statistics |
| plperl | 1.0 | PL/Perl procedural language |
| plperlu | 1.0 | PL/PerlU untrusted procedural language |
| plpgsql | 1.0 | PL/pgSQL procedural language |
| plpython2u | 1.0 | PL/Python2U untrusted procedural language |
| plpythonu | 1.0 | PL/PythonU untrusted procedural language |
| pltcl | 1.0 | PL/Tcl procedural language |
| pltclu | 1.0 | PL/TclU untrusted procedural language |
| postgis | 3.0.0 | PostGIS geometry, geography, and raster spatial types and functions |
| postgis_raster | 3.0.0 | PostGIS raster types and functions |
| postgis_sfcgal | 3.0.0 | PostGIS SFCGAL functions |
| postgis_tiger_geocoder | 3.0.0 | PostGIS tiger geocoder and reverse geocoder |
| postgis_topology | 3.0.0 | PostGIS topology spatial types and functions |
| postgres_fdw | 1.0 | foreign-data wrapper for remote PostgreSQL servers |
| refint | 1.0 | functions for implementing referential integrity (obsolete) |
| seg | 1.3 | data type for representing line segments or floating-point intervals |
| sslinfo | 1.2 | information about SSL certificates |
| tablefunc | 1.0 | functions that manipulate whole tables, including crosstab |
| tcn | 1.0 | Triggered change notifications |
| timetravel | 1.0 | functions for implementing time travel |
| tsm_system_rows | 1.0 | TABLESAMPLE method which accepts number of rows as a limit |
| tsm_system_time | 1.0 | TABLESAMPLE method which accepts time in milliseconds as a limit |
| unaccent | 1.1 | text search dictionary that removes accents |
| uuid-ossp | 1.1 | generate universally unique identifiers (UUIDs) |
| xml2 | 1.1 | XPath querying and XSLT |
If you need an extension not listed above, please let us know and we can investigate further.
Database Types
Cloud SQL instances have an associated Database Type which describes the RAM, CPU and disk storage resources allocated to it.
Changing Database Type
Cloud SQL instances can be resized by changing to a larger type.
Access
Network access
Cloud SQL Instances are made accessible over the network by mapping a Cloud IP to them.
Admin password
When a new instance is created, admin credentials are automatically generated by the API. The credentials are only displayed at create time, since the admin password is not stored by the API, so cannot be retrieved later.
The admin password can be reset at any time, using the “Reset admin password” action.
Cloud SQL instances created from a snapshot inherit the admin password from the snapshot, rather than generating a new one.
Cloud SQL Snapshots
Creating a snapshot produces an instant and consistent copy of a Cloud SQL instance stored in Orbit, our highly-available object storage service.
Although the snapshot itself is instantaneous, the copy process may take several minutes depending on the size of the data and the current load on the instance.
During the copy process, the snapshot is initially held on the instance itself which means that the instance cannot be destroyed until the snapshot copy is completed. Once complete, the snapshot is stored to the images Orbit storage container.
Cloud SQL Snapshots can be used to as a starting point for new instances, providing the ability to essentially clone (or “fork”) an existing Cloud SQL instance.
Automated Snapshots
Snapshots can be created manually at any time and also automatically by specifying an automated snapshot schedule.
The snapshot schedule enables an automated snapshot to be created each day, each week or each month at a specified time.
By default, new Cloud SQL instances schedule a daily automated snapshot.
Snapshot Retention Policy
The automated snapshot retention policy describes the maximum number of automated snapshots which should be kept. When the number of automated snapshots exceeds this number, the oldest snapshot will be deleted to maintain the specified retention count.
The retention policy will only delete excess automated snapshots and will not delete manual snapshots.
By default, the retention policy is to keep all automated snapshots i.e not to delete any automatically.
Weekly maintenance window
Minor version updates to the database engine are automatically applied during a weekly one hour maintenance window.
The maintenance window can be set to any hour during the week but defaults to Sunday morning between 06:00am and 07:00am UTC.
During any updates, service can be interrupted for short periods of time if the instance needs to be restarted.
Minor version updates are from the upstream vendor, and will usually only contain bug and security patches.
Billing
Cloud SQL instances are billed by the hour, starting from the time the instance is first created until it is destroyed. Data transfer between instance and the Internet is billed per gigabyte at the standard Internet data rates. Data between Cloud SQL instances and cloud servers is free.
Cloud SQL snapshot storage is billed per gigabyte at the Orbit storage rate.