Explanation
Why the waste happens and who it affects.
The service checks available storage every 30 seconds and adds capacity when free space drops below a threshold, and by default there is no upper limit. Google documents these increases as permanent: the disk never shrinks back on its own. A one-off event such as a bulk load, a migration, an index rebuild or a temporary pile-up of logs or temporary files can push provisioned storage far above what the database needs afterward.
Because storage is billed on provisioned capacity rather than on data used, the instance keeps paying for the enlarged disk every month after the spike is gone. Cloud SQL supports shrinking storage manually in all editions, but the operation requires downtime, so oversized disks tend to persist, and HA instances pay for the extra capacity at HA storage rates.
Billing model
The pricing dimensions that drive this cost.
- Provisioned storage capacity
- SSD, HDD or Hyperdisk Balanced capacity billed per GiB of provisioned size over time, regardless of how much is used
- HA storage
- Regional (HA) instances pay HA storage rates, double the zonal rate
- Automatic storage increase
- Adds capacity when free space runs low; increases are permanent unless storage is manually shrunk
- Read replica storage
- Billed separately for each replica, and a replica cannot have less storage than its primary
How to detect
4 checks to find it in your estate.
- Compare cloudsql.googleapis.com/database/disk/bytes_used with database/disk/quota per instance, or chart database/disk/utilization, and flag instances with a large, persistent gap
- Look for step increases in database/disk/quota that were not followed by sustained growth in bytes used, which indicates a one-off spike
- Run gcloud sql instances get-storage-shrink-config INSTANCE to see minimalTargetSizeGb, the smallest size Cloud SQL considers safe, and the estimated duration of a shrink
- Check whether a storage auto increase limit is set; the default of 0 means no cap
How to fix
4 ways to remove the waste.
- Shrink storage with gcloud sql instances perform-storage-shrink INSTANCE --storage-size=TARGET_GB; the target must be above minimalTargetSizeGb, and Google recommends keeping a buffer of 100 GB or 20% of current usage, whichever is larger
- Plan for downtime: the instance restarts when the operation completes and large disks can take considerable time; take a backup first, schedule a maintenance window, and check IOPS needs because a smaller disk can lower IOPS; Google suggests Database Migration Service to a smaller instance when downtime must be minimal
- Shrink the primary first, then its read replicas, which cannot be smaller than the primary; the MySQL legacy HA configuration and cascading replicas are not supported
- Set an automatic storage increase limit on instances with a known growth profile, and clean up the cause of the spike (for example oversized temporary tables, bulk-load staging data or retained logs) so storage does not grow again
Documentation
Vendor references for pricing and configuration.