africa-south1
— Johannesburgasia-east1
— Taiwanasia-east2
— Hong Kongasia-northeast1
— Tokyoasia-northeast2
— Osakaasia-northeast3
— Seoulasia-south1
— Mumbaiasia-south2
— Delhiasia-southeast1
— Singaporeasia-southeast2
— Jakartaaustralia-southeast1
— Sydneyaustralia-southeast2
— Melbourneeurope-central2
— Warsaweurope-north1
— Finlandeurope-southwest1
— Madrideurope-west1
— Belgiumeurope-west2
— Londoneurope-west3
— Frankfurteurope-west4
— Netherlandseurope-west6
— Züricheurope-west8
— Milaneurope-west9
— Pariseurope-west10
— Berlineurope-west12
— Turinme-central1
— Dohame-central2
— Dammamme-west1
— Tel Avivnorthamerica-northeast1
— Montréalnorthamerica-northeast2
— Torontosouthamerica-east1
— San Paulosouthamerica-west1
— Santiagous-central1
— Iowaus-east1
— South Carolinaus-east4
— Northern Virginiaus-east5
— Columbusus-south1
— Dallasus-west1
— Oregonus-west2
— Los Angelesus-west3
— Salt Lake Cityus-west4
— Las Vegasafrica-south1
— Johannesburgasia-east1
— Taiwanasia-east2
— Hong Kongasia-northeast1
— Tokyoasia-northeast2
— Osakaasia-northeast3
— Seoulasia-south1
— Mumbaiasia-south2
— Delhiasia-southeast1
— Singaporeasia-southeast2
— Jakartaaustralia-southeast1
— Sydneyaustralia-southeast2
— Melbourneeurope-central2
— Warsaweurope-north1
— Finlandeurope-north2
— Stockholmeurope-southwest1
— Madrideurope-west1
— Belgiumeurope-west2
— Londoneurope-west3
— Frankfurteurope-west4
— Netherlandseurope-west6
— Züricheurope-west8
— Milaneurope-west9
— Pariseurope-west10
— Berlineurope-west12
— Turinme-central1
— Doha me-central2
— Dammamme-west1
— Tel Avivnorthamerica-northeast1
— Montréalnorthamerica-northeast2
— Torontonorthamerica-south1
- Mexicosouthamerica-east1
— São Paulosouthamerica-west1
— Santiagous-central1
— Iowaus-east1
— South Carolinaus-east4
— Northern Virginiaus-east5
— Columbusus-south1
— Dallasus-west1
— Oregonus-west2
— Los Angelesus-west3
— Salt Lake Cityus-west4
— Las VegasConsole string API enum string PostgreSQL 17POSTGRES_17
PostgreSQL 16 (default)POSTGRES_16
PostgreSQL 15POSTGRES_15
PostgreSQL 14POSTGRES_14
PostgreSQL 13POSTGRES_13
PostgreSQL 12POSTGRES_12
Console string API enum string PostgreSQL 17POSTGRES_17
PostgreSQL 16 (default)POSTGRES_16
PostgreSQL 15POSTGRES_15
PostgreSQL 14POSTGRES_14
PostgreSQL 13POSTGRES_13
PostgreSQL 12POSTGRES_12
PostgreSQL 11POSTGRES_11
PostgreSQL 10POSTGRES_10
PostgreSQL 9.6POSTGRES_9_6
ALLOW_UNENCRYPTED_AND_ENCRYPTED
: allows non-SSL/non-TLS and SSL/TLS connections. For SSL connections, the client certificate isn't verified. This is the default value.ENCRYPTED_ONLY
: only allows connections encrypted with SSL/TLS.TRUSTED_CLIENT_CERTIFICATE_REQUIRED
: only allows connections encrypted with SSL/TLS and with valid client certificates.Lets you configure the server certificate authority (CA) for an instance. You can select one of the following available server CA options:
GOOGLE_MANAGED_INTERNAL_CA
: this is the default value for instances created with the gcloud CLI, the Cloud SQL Admin API, or Terraform. With this option, an internal CA dedicated to each Cloud SQL instance signs the server certificate for that instance.GOOGLE_MANAGED_CAS_CA
: with this option, a CA hierarchy consisting of a root CA and subordinate server CAs managed by Cloud SQL and hosted on Google Cloud Certificate Authority Service (CA Service) is used. The subordinate server CAs in a region sign the server certificates and are shared across instances in the region.CUSTOMER_MANAGED_CAS_CA
: with this option, you manage the CA hierarchy and the rotation of CA certificates. Before you can create an instance with this option, using CA Service, you create a CA pool in the same region as your instance and at least one CA in that pool. When you create your instance, you specify the CA pool. Your request is delegated to a project-specific service account, which has the permission to use the CA pool. The service account requests a CA from the pool and Cloud SQL uses that CA to sign the server certificate for the instance. For more information, see Certificate authority (CA) hierarchies. This instance setting is in Preview.
ENTERPRISE
or ENTERPRISE PLUS
db-perf-optimized-N-128
machine type only. All other machine types have the 8 GB to 1 vCPU ratio. There is also a drop-down menu with a list of multi-regions when you select Multi-region or regions when you select Region.
The default value varies by instance. For more information, see Use PITR.
The instance ID is the name of the instance. It is used to uniquely identify your instance within the project. Choose an instance name that is aligned with the purpose of the instance when possible.
The total length of project-ID:instance-ID
must be 98 characters or less.
Determines memory and virtual cores available for your Cloud SQL instance. Machine types are part of a machine series, and machine series availability is determined by your Cloud SQL edition.
For Cloud SQL Enterprise Plus edition instances, Cloud SQL offers predefined machine types for your instances in the N2
and C4A
machine series.
For Cloud SQL Enterprise edition instances, Cloud SQL offers predefined and custom machine types.
If you require real-time processing, such as online transaction processing (OLTP), make sure that your instance has enough memory to contain the entire working set. However, there are other factors that can impact memory requirements, such as number of active connections, and internal overhead processes. Perform load testing to avoid performance issues in your production environment.
When you configure your instance, select sufficient memory and vCPUs to handle your needs, and scale up your instance as your requirements increase. A machine configuration with insufficient vCPUs might lose its SLA coverage. For more information, see Operation guidelines.
To learn more about the machine types and machine series available for your Cloud SQL instance, see Machine series overview.
Your machine type affects the cost of your instance. For more information, see Instance Pricing. You can also see pricing for various scenarios with the Pricing Calculator.
The password policy for the instance. It includes the following options:
The number of CPUs for your instance. You can also choose to create an instance with less than one CPU (a shared code instance, or shared vCPU).
The amount of memory available for your instance. For performance-sensitive workloads such as online transaction processing (OLTP), make sure that your instance has enough memory to contain the entire working set. However, there are other factors that can impact memory requirements, such as number of active connections. Perform load testing to avoid performance issues in production.
gcloud
command and REST API usage, see the reference documentation. Storage type is determined by the machine type you select for your instance. Each machine type belongs to a specific machine series, and each machine series offers different storage type options.
Storage type by machine series:
For the N2 machine series, choosing SSD, the default value, provides your instance with SSD storage. SSDs provide lower latency and higher data throughput. If you don't need high-performance access to your data, for example for long-term storage or rarely accessed data, you can reduce your costs by choosing HDD.
For the C4A machine series, choosing Hyperdisk Balanced, the default and only value, provides a scalable, high-performance storage service. To learn more about Hyperdisk Balanced and its limitations, see Storage options overview.
(Optional) The SSL/TLS options for a database connection. Cloud SQL uses SSL/TLS to establish secure, authenticated, and encrypted connections to instances. You can use the SSL mode setting sslMode
to enforce all database connections to an instance to use SSL/TLS encryption. You can also use this setting to enforce verification of client certificates. This setting gives you more granular controls over your SSL connections compared to requireSsl
. We recommend that you use sslMode
. For more information, see IpConfiguration. You can enforce SSL when you create an instance or update it for any existing instance.
(Optional) When you create an instance, you can select the server CA mode for the instance.
GOOGLE_MANAGED_INTERNAL_CA
: this is the default value. Cloud SQL creates a new self-signed server CA for each instance.GOOGLE_MANAGED_CAS_CA
: the instance uses a server CA hierarchy hosted by Certificate Authority Service and the issuing CAs are shared across all instances in the same region. For more information about these options, see Certificate authority (CA) hierarchies. Server CA mode is in Preview.
Choose a capacity to fit your database size. After you have created your instance, you can manually increase the storage capacity by editing your instance configuration, but you cannot decrease it. Increasing the storage capacity does not cause downtime.
The amount of storage capacity allocated for your instance affects the cost of your instance. For more information, see Storage and Networking Pricing.
For read replicas, the storage capacity must always be at least as high as the storage capacity of the primary instance. When a primary instance is resized, all read replicas are resized, if needed, so that they have at least as much storage capacity as the updated primary instance.
If you enable this setting, Cloud SQL checks your available storage every 30 seconds. If the available storage falls below a threshold size, Cloud SQL automatically adds additional storage capacity. If the available storage repeatedly falls below the threshold size, Cloud SQL continues to add storage until it reaches the maximum of 64 TB.
The automatic storage increase setting of a primary instance automatically applies to any read replicas of that instance. The automatic storage increase setting cannot be independently set for read replicas.
The threshold size depends on the amount of storage currently provisioned for your instance; it cannot be larger than 25 GB.
For instances provisioned with 500 GB of storage (or more), the threshold is always 25 GB.
For instances provisioned with less than 500 GB of storage, this formula is used to calculate the threshold:
5 + (provisioned storage)/25
The result of the division is rounded down to the nearest whole number.
Threshold calculation for an instance with 66 GB storage capacity:
5 + (1/25th of 66 GB) = 5 + (66/25) = 5 + 2.6 -> 5 + 2 = 7 GB
5 + (1/25th of 1000 GB) = 5 + (1000/25) = 5 + 40 = 45 -> rounded down to the maximum value of 25 GB
The amount of storage added to the instance is equal to the threshold size, which cannot be larger than 25 GB.
For instances provisioned with storage of 500 GB or more, the threshold size is always 25 GB and the amount of storage added is always 25 GB. As a result, the maximum possible empty space is 50 GB. If you do not manually resize the instance with disk greater than 5 TB, the disk can remain at 99% capacity all the time even though the instance has empty space.
Before an operation that rapidly grows disk space usage, such as a large import or a query that requires a large temp table, manually resize the disk, rather than depend on automatic storage increase to keep up.
The file system uses some space internally for file system metadata. This space isn't included in the disk usage metric (database/disk/bytes_used
). For large disks, the reserved space can take 1% to 3% of total disk size, so you might see the automatic storage increase occur before the disk usage reaches the threshold.
By default, your Cloud SQL instance is encrypted with a Google-owned and managed key. If you want to control this key, then use a customer-managed encryption key (CMEK) in Cloud Key Management Service (KMS). Cloud KMS integrates with Cloud SQL.
Using Cloud KMS keys gives you control over their protection level, location, rotation schedule, usage and access permissions. In addition, you can use various encryption keys across resources. Using Cloud KMS also lets you track key usage, view audit logs, and control key life cycles.
Instead of Google owning and managing the keys that protect your data, you control and manage these keys in Cloud KMS.
For more information about CMEKs, see About customer-managed encryption keys (CMEKs).
If you enable the automatic storage increase setting, you can provide a specific limit on how large the storage for your instance can automatically grow. Keep in mind that the bigger the size of the instance, the greater the operational latency.
You can't decrease storage size, so this limit can prevent your instance size from growing too large (due to a temporary increase in traffic). Keep in mind that when an instance becomes unable to add storage that it needs, the instance likely stops accepting incoming connections and could go offline.
Setting this limit to zero, the default value, means that there is no limit (other than the maximum available storage for the instance tier).
To set the limit when you create the instance, use the --storage-auto-increase-limit=INTEGER_VALUE_OF_GB
parameter, as described on the create instance page. To set the limit on an existing instance, use the same parameter with the gcloud beta sql instances patch
command.
The automatic storage increase limit setting of a primary instance automatically applies to any read replicas of that instance. The automatic storage increase limit setting cannot be independently set for read replicas.
These options determine if automated backups are performed and if write-ahead logging is enabled. Both options add a small performance cost and use additional storage, but are required for the creation of replicas and clones, and for point-in-time recovery. When you select this option, you can also select a timeframe when automated backups occur.
Automated backups happen daily, during the time window you choose. At the end of seven days, the oldest backup is deleted.
For information about point-in-time recovery, see Overview of point-in-time recovery.
For information about replication, see Replication Options. For information about cloning instances, see Cloning Instances.
The default value for the number of retained backups is 7 but you can change it to any value in the range of 1 to 365.
See Automated backup and transaction log retention for more information.
You can choose to store backups in multiple or single regions. Multi-region is the default, and the recommended choice because it provides protection against downtime when a region becomes unavailable. Backups are stored in regions that are closest to the instance.
You also have the option of selecting a custom location for your backup. Only use this option if required by regulation or if an organization policy requires your backups to be in specific multiple or single regions. See Custom locations for more information.
Protects an instance against accidental deletion. If this setting is enabled, you must deactivate it before deleting the instance. See Prevent deletion of an instance.
Retains on-demand and automated backups for an instance after the instance is deleted. For more information about this setting, see Retained backups.
Point-in-time recovery lets you recover from a backup, starting from a specific point in time.
For information about point-in-time recovery, see Overview of point-in-time recovery.
Puts your instance and backups in a single zone. When you select this option, there is no failover in the event of an outage. Recommended only for test and development purposes.
When you select High availability (regional), if there is an outage, your instance fails over to another zone in the region where your instance is located, as long as the failover zone is not having an outage. It is recommended that you select High availability (regional) for instances in your production environment.
The day and hour that your maintenance events for the Cloud SQL instance are scheduled. For Cloud SQL Enterprise Plus edition primary instances, the maintenance downtime is typically less than 1 second. For all other instances, maintenance downtime is typically 60 seconds or less on average.
Read replicas do not support maintenance window settings at this time.
For more information about maintenance, see About maintenance on Cloud SQL instances.
Your preference about the relative timing of maintenance updates. You can receive your updates one or two weeks after the notification and test your maintenance updates in a test environment before your production instances get the update. You can also choose to receive the maintenance update five weeks ("week5
") after the notification is sent out. The maintenance timing setting doesn't affect the maintenance version that Cloud SQL applies to your instance.
If you don't set the maintenance timing setting, Cloud SQL chooses the timing of updates to your instance (within its maintenance window, if applicable).
For more information about maintenance, see About maintenance on Cloud SQL instances.
For information about configuring IP addresses, see Configuring IP connectivity.
By selecting this check box, you allow other Google Cloud services, such as BigQuery, to access data in Cloud SQL and make queries against this data over a private connection.
This check box is enabled only if you select the Private IP check box, and you add or select an authorized network to create a private connection.
Data cache is optional for Cloud SQL for PostgreSQL Enterprise Plus edition instances. Data cache utilizes local SSDs to extend the OS page cache from memory to the SSD tier. Cloud SQL manages this setting. Caching your entire working set provides maximum performance when using data cache. You can use the Google Cloud console, gcloud CLI, or Cloud SQL Admin API to turn this setting on or off for your Cloud SQL for PostgreSQL Enterprise Plus edition instances.
You can set specific database flags on the Cloud SQL instance.
For a complete list of the database flags you can set, see Configure Database Flags.
For most instance settings, Cloud SQL applies the change immediately and connectivity to the instance is unaffected.
If you're using Cloud SQL Enterprise edition, then changing the number of CPUs or the memory size results in the instance going offline for less than 60 seconds. The total time for the changes to take effect can take several minutes. Changing an instance's zone, configuring the private IP, changing its network, and enabling high availability results i n the instance going offline for several minutes.
If you're using Cloud SQL Enterprise Plus edition, then you can make some instance setting changes, such as scaling up vCPUs or enabling or disabling data cache, with near-zero downtime. For more information, see Availability in Cloud SQL.
Cloud SQL automatically manages the value of the max_connections
flag based on the amount of memory on the instance (for more information, see supported flags). PostgreSQL requires that the value of max_connections
is always at least as large on a read replica as it is on its primary. Therefore, if the read replicas have less memory than the primary, changing the amount of memory on the primary might result in its read replicas going offline for less than 60 seconds. This happens because the read replicas might need to receive a new value of max_connections
to remain consistent with the change on the primary, and updating the value of max_connections
requires restarting PostgreSQL. To prevent this from happening, set the max_connections
flag on the primary to a value of your choice.
Plan to make these kinds of changes when your service can handle an outage of this duration.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-04-17 UTC.