Cloud SQL Cost Optimisation: Pausing, Right-Sizing, and HA Settings
Cloud SQL is often the most expensive managed service in a standard GCP deployment because it bills for vCPU and memory continuously, whether queries are running or not. The biggest savings come from pausing idle dev instances, right-sizing production tiers, and disabling HA replicas where they are not needed.
Pause dev and staging instances
A running Cloud SQL instance is like leaving the lights and heating on in an office overnight. The building is empty, nobody is using it, but you are still paying the full electricity bill. Pausing an instance is like flipping the switch when the last person leaves. The building is still there and you can turn it back on in the morning.
A dev Cloud SQL instance running the same tier as production costs the same per hour. If developers only use it during business hours, it runs idle 16 hours per day and all weekend, paying for compute nobody is using.
Pausing an instance sets its activation policy to NEVER, which stops vCPU
and memory billing. Storage charges continue, but compute is the dominant cost. A
2-vCPU instance costs roughly $65-90/month running continuously versus near-zero while
paused.
# Pause a dev Cloud SQL instance (stops CPU/memory billing, storage continues)
gcloud sql instances patch my-dev-instance \
--activation-policy=NEVER
# Resume when needed
gcloud sql instances patch my-dev-instance \
--activation-policy=ALWAYSAutomate pausing with Cloud Scheduler. Set a job to pause dev instances at 7 PM and resume them at 8 AM on weekdays. Running only 8 hours per day on weekdays cuts compute costs by roughly 76%.
Right-size production tiers
Cloud SQL instances are often provisioned conservatively at launch and never revisited.
Use Cloud Monitoring to check actual CPU and memory utilisation. If a db-custom-4-16384
(4 vCPUs, 16 GB RAM) instance rarely exceeds 40% CPU, a db-custom-2-8192
may handle the workload at half the price.
# Check current Cloud SQL instance tier
gcloud sql instances describe my-instance \
--format="value(settings.tier,settings.diskSize)"
# Resize to a smaller tier (requires instance restart)
gcloud sql instances patch my-instance \
--tier=db-custom-2-8192 # 2 vCPUs, 8 GB RAMResizing requires a brief restart. Schedule it during a maintenance window and use billing data to confirm the savings afterward.
HA and redundancy settings
Enabling high availability on a Cloud SQL instance creates a standby replica in a different zone. This roughly doubles vCPU and memory charges. HA is correct for production databases where downtime is unacceptable, but it is unnecessary overhead for dev, staging, and test environments.
- Production: Keep HA enabled. The cost is justified by the automatic failover and reduced downtime risk.
- Dev and staging: Disable HA. If the instance goes down, developers can wait for it to restart without business impact.
- Read replicas: Each read replica is an additional instance with its own compute costs. Only add replicas when read traffic actually requires them, not as a precaution.
Disabling HA on a production instance to save money is a false economy. A single unplanned outage can cost far more in downtime and recovery effort than the standby replica costs in a year. Reserve HA savings for non-production environments only.
Storage auto-increase
Cloud SQL storage can only be increased, never decreased. Once auto-increase fires because the disk fills up, the instance keeps the larger disk permanently, even if you delete the data that triggered the increase.
A runaway batch job or log table that fills the disk will trigger auto-increase. Even after you clean up the data, the disk stays at the larger size and you pay for it indefinitely. There is no way to shrink it without recreating the instance.
To avoid over-provisioning: start with a disk size that matches your expected data volume, monitor storage growth in Cloud Monitoring, and consider disabling auto-increase for databases with predictable workloads so you can manage increases manually at a pace that matches actual need.
Common beginner mistakes
Running dev Cloud SQL instances 24/7. A dev instance with the same tier as production costs the same per hour. Pause it when not in use. Running only during business hours cuts compute costs by roughly 76%.
Never revisiting the instance tier after initial provisioning. Teams provision conservatively for launch, then never check whether the instance is actually using the CPU and memory they are paying for. Review utilisation quarterly.
Enabling HA on non-production instances. HA doubles compute cost. Dev and staging databases do not need automatic failover.
Relying on storage auto-increase without monitoring. Auto-increase is a safety net, not a strategy. Once it fires, you cannot shrink the disk. Monitor storage growth and plan increases deliberately.
Summary
- Pause dev and staging Cloud SQL instances when not in use to stop vCPU/memory billing (storage continues)
- Right-size production tiers by checking actual CPU and memory utilisation in Cloud Monitoring
- Disable HA on non-production instances to cut compute cost in half
- Cloud SQL storage only increases, never decreases. Manage disk size deliberately
- Review Cloud SQL costs regularly using cost breakdown reports
Frequently asked questions
How much does a Cloud SQL instance cost when not in use?
A running Cloud SQL instance bills for vCPU and memory continuously regardless of query load. A 2-vCPU PostgreSQL instance in us-central1 costs roughly $65-90/month in compute alone, plus storage. For dev and staging Cloud SQL instances, use the pause feature (sets activation-policy to NEVER) to stop compute billing when not in use. Paused instances still bill for storage but not CPU or memory.
Does Cloud SQL HA double my costs?
Yes. Enabling high availability creates a standby replica that doubles vCPU and memory charges. This is correct for production databases where downtime is unacceptable, but it is unnecessary for dev, staging, and test instances. Disable HA on non-production instances to cut their compute cost in half.
Can I reduce Cloud SQL storage once it has auto-increased?
No. Cloud SQL storage can only increase, never decrease. Once auto-increase fires, the instance keeps the larger disk permanently even if you delete the data. To avoid over-provisioning, start with a conservative disk size, monitor growth, and consider managing increases manually for databases with predictable workloads.