# Oversized Cloud SQL Storage After Automatic Storage Increase Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/oversized-cloud-sql-storage-after-automatic-storage-increase Cloud SQL enables automatic storage increase by default. The service checks available storage every 30 seconds and adds capacity when free space drops... By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version Cloud SQL enables automatic storage increase by default. PointFive Research Cloud cost research at PointFive GCP service [GCP Cloud SQL](https://www.pointfive.co/efficiency-hub/cloud-services/gcp-cloud-sql) Category [Databases](https://www.pointfive.co/efficiency-hub/service-category/databases) Reference CER-0478 Type Overprovisioned Resource ## 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. - [About storage shrink docs.cloud.google.com](https://docs.cloud.google.com/sql/docs/mysql/about-storage-shrink) - [Shrink instance storage capacity docs.cloud.google.com](https://docs.cloud.google.com/sql/docs/mysql/shrink-instance-storage-capacity) - [About instance settings docs.cloud.google.com](https://docs.cloud.google.com/sql/docs/mysql/instance-settings) - [Cloud SQL pricing cloud.google.com](https://cloud.google.com/sql/pricing) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - GCP Cloud SQL CER-0183 ### [Underutilized Cloud SQL Instance](https://www.pointfive.co/efficiency-hub/inefficiencies/underutilized-cloud-sql-instance) Cloud SQL instances are often over-provisioned or left running despite low utilization. Since billing is based on allocated vCPUs, memory, and storage - not usage - any misalignment between actual workload needs and provisioned capacity... Databases - GCP Cloud SQL CER-0279 ### [Excessive Automated Backup Retention in Cloud SQL](https://www.pointfive.co/efficiency-hub/inefficiencies/excessive-automated-backup-retention-in-cloud-sql) Automated Cloud SQL backups are retained longer than required by recovery objectives or governance needs. Because backups accumulate over the retention window (and can grow quickly for high-change databases), excessive retention drives... Databases - GCP Cloud SQL CER-0475 ### [Idle Cloud SQL Instance](https://www.pointfive.co/efficiency-hub/inefficiencies/idle-cloud-sql-instance) An idle Cloud SQL instance is one that is still running but no longer serves any workload: no meaningful connections, queries or data changes. Common sources are databases left behind after a migration, instances created for a test or... Databases --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.