This page provides information about the settings available for Google Cloud SQL instances.
|Setting||Modifiable after creation?||Possible values|
|Instance ID||N||Composed of lowercase letters, numbers, and hyphens; must start with a letter.|
|Database version||N||PostgreSQL 9.6|
|Zone||Y||The possible values depend on the region.
1 to 32 (must be either 1 or an even number)
Partial for shared vCPU
|Memory||Y||0.9 to 6.5 GiB per vCPU (must be a multiple of 256 MiB and at least 3.75 GiB)|
SSD (default value)
Instances with at least one (unshared) vCPU can have up to 10230 GB.
Instances with a shared vCPU can have up to 3062 GB.
|Automatic storage increase||Y||
On (default value)
On (default value)
|Maintenance window||Y||Day of the week, and hour.|
Any (default value)
|Authorized networks||Y||IP addresses or ranges of addresses, in CIDR notation.|
|Cloud SQL flags||Y||See Configuring Cloud SQL Flags.|
- Instance ID
- 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. Instance names must have 98 characters or less. You do not need to prepend the project ID onto the instance ID. This is done automatically where appropriate (for example, in the log files). ...see naming guidelines
- The Google Cloud Platform region where your instance is located. To improve performance, keep your data close to the services that need it. For more information, see Instance Locations.
- The Google Cloud Platform zone where your instance is located. If you are connecting from a Compute Engine instance, select the zone where the Compute Engine instance is located. Otherwise, you should accept the default zone. For more information, see Instance Locations.
- 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 best performance, choose a memory size that can accommodate your largest table.
- Database version
- Unless you need a capability provided only by a specific version, you should accept the default database version.
- Storage type
- Choosing SSD, the default value, provides your instance with SSD storage. SSDs provide lower latency and higher data throughput. If you do not 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.
- Storage capacity
- Choose a capacity to fit your database size. After you have created your instance, you can increase your storage capacity, but you cannot decrease it. The amount of storage capacity allocated for your instance affects the cost of your instance.
- Automatic storage increase
If this setting is enabled, your available storage is checked every 30 seconds. If available storage falls below a threshold size, additional storage capacity is automatically added to your instance.
The size of the threshold and the amount of storage that is added to your instance depends on the amount of storage currently provisioned for your instance, up to a maximum size of 25 GB. The current storage capacity is divided by 25, and the result rounded down to the nearest integer. This result is added to 5 GB to produce both the threshold size and the amount of storage that is added in the event that the available storage falls below the threshold.
Threshold for an instance with 66 GB storage capacity:
5 + (1/25th of 66-GB capacity) = 5 + (66/25) = 5 + 2.6 -> 5 + 2 = 7 GBThreshold for an instance with 130 GB storage capacity:
5 + (1/25th of 130-GB capacity) = 5 + (130/25) = 5 + (5.2) -> 5 + 5 = 10 GBThreshold for an instance with 1000 GB storage capacity:
5 + (1/25th of 1000-GB capacity) = 5 + (1000/25) = 5 + 40 -> min(45, 25) = 25 GB
- This setting determines whether automated backups are performed.
- Maintenance window
The day and hour when disruptive updates (updates that require an instance restart) to this Cloud SQL instance can be made. If the maintenance window is set for an instance, Cloud SQL does not initiate a disruptive update to that instance outside of the window. The update is not guaranteed to complete before the end of the maintenance window, but restarts typically complete within a couple of minutes.
If you do not specify a maintenance window, disruptive updates can happen at any time, although they generally only occur every few months.
- Maintenance timing
This setting lets you provide a preference about the relative timing of instance updates that require a restart. Receiving updates earlier lets you test your application with an update before your instances that get the update later.
The relative timing of updates is not observed between projects; if you have instances with an earlier timing setting in a different project than your instances with a later timing setting, Cloud SQL makes no attempt to update the instances with the earlier timing setting first.
If you do not set the Maintenance timing setting, Cloud SQL chooses the timing of updates to your instance (within its Maintenance window, if applicable).
The Maintenance timing setting does not affect the software version Cloud SQL applies to your instance.
- You can add specific IP addresses or ranges of addresses to open your instance to those addresses.
This is required if you do not use the Cloud SQL Proxy.
For information about configuring IP addresses, see Configuring access for IP connections.
For information about configuring the Cloud SQL Proxy, see Using the Proxy.
- Activation policy
- The activation policy is used only to start or stop the instance. Setting the activation policy to ALWAYS starts the instance, and setting it to NEVER stops the instance.
- Cloud SQL flags
- You can set specific Cloud SQL flags on the Cloud SQL instance.
For a complete list of the Cloud SQL flags you can set, see Configuring Cloud SQL Flags.
Impact of changing instance settings
For most instance settings, Google Cloud SQL applies the change immediately and connectivity to the instance is unaffected.
Changing the number of CPUs, memory size, or the zone of the instance results in the instance going offline for several minutes. You should plan to make these kind of changes when your application can handle an outage of this length.
Learn how to edit your instance.