Cloud SQL Auto Storage Increase Disabled: Why It Matters and How to Fix It

Running out of disk on a managed database is one of those failures that feels almost too simple to take you down, yet it does, regularly, and usually at the worst possible moment. On Google Cloud SQL the symptom is brutal: when the data disk fills up, the instance stops accepting writes. Reads may keep working for a while, but anything that mutates state, including the writes your application depends on, starts failing. This Lensix check looks for Cloud SQL instances that have automatic storage increase turned off, which is the configuration that prevents this exact outage.

---

What this check detects

The sql_noautostorageincreasse check inspects each Cloud SQL instance in your GCP project and reports any instance where the automatic storage increase setting is disabled.

Cloud SQL provisions a fixed amount of SSD or HDD storage for each instance. With automatic storage increase enabled, Cloud SQL monitors available space and grows the disk automatically when free capacity drops below a threshold. With it disabled, the disk stays at whatever size you originally set, and once it is full, write operations fail.

In the API, the relevant field lives under settings.storageAutoResize. When this is false, the check fails. You can confirm the current state for a single instance like this:

gcloud sql instances describe my-instance \
  --format="value(settings.storageAutoResize)"

A return value of False means the instance is exposed.

---

Why it matters

The risk here is not subtle. A full data disk on Cloud SQL produces a hard write failure. The database does not gracefully degrade, it stops persisting new data. For most production systems that means transactions fail, queues back up, and user-facing operations return errors.

A few realistic ways this plays out:

• Organic growth. Your data volume creeps up over months. Nobody is watching the disk metric closely because everything has worked fine, and then one Tuesday the instance crosses 100 percent and writes stop.
• A logging or audit table runs away. A feature ships that writes far more rows than expected, or log rotation breaks, and the disk fills in hours rather than months.
• Binary logs and WAL accumulation. Replication lag or a stuck replica can cause transaction logs to pile up faster than they are purged, consuming space you did not budget for.
• A bulk import. Someone runs a large data migration or backfill and the disk that had comfortable headroom yesterday is full halfway through the job.

Recovery from a full disk is slower and more stressful than it should be. You can manually increase storage to bring the instance back, but you are doing it under pressure while writes are failing, and the resize itself takes time to apply. Automatic storage increase removes the human from this loop entirely.

There is also a business continuity angle worth naming for compliance and reliability reviews. A predictable, self-healing storage configuration is far easier to defend during an audit than a static disk size that depends on someone remembering to grow it.

---

How to fix it

Enabling automatic storage increase is a non-disruptive change. It does not require downtime and applies immediately.

Using the gcloud CLI

gcloud sql instances patch my-instance \
  --storage-auto-increase

You can also set the threshold that controls how much additional headroom Cloud SQL maintains. The storage auto increase limit caps how large the disk is allowed to grow automatically (a value of 0 means no limit, bounded only by the maximum for the tier):

gcloud sql instances patch my-instance \
  --storage-auto-increase \
  --storage-auto-increase-limit=500

The command above caps automatic growth at 500 GB. Setting a sensible limit is a good idea so a runaway process cannot quietly inflate your bill to a five figure storage charge.

Using the Google Cloud Console

1. Open SQL in the Google Cloud Console and select your instance.
2. Click Edit.
3. Expand the Storage section.
4. Check Enable automatic storage increases.
5. Optionally set a storage limit to cap automatic growth.
6. Click Save.

Using Terraform

If you manage Cloud SQL with Terraform, the relevant attributes live in the settings block of google_sql_database_instance:

resource "google_sql_database_instance" "main" {
  name             = "my-instance"
  database_version = "POSTGRES_15"
  region           = "us-central1"

  settings {
    tier              = "db-custom-2-7680"
    disk_size         = 50
    disk_autoresize   = true
    disk_autoresize_limit = 500
  }
}

Set disk_autoresize = true and define disk_autoresize_limit to bound growth. Apply the change and Terraform will patch the instance in place.

for inst in $(gcloud sql instances list \
  --filter="settings.storageAutoResize=false" \
  --format="value(name)"); do
    echo "Enabling auto storage increase on $inst"
    gcloud sql instances patch "$inst" \
      --storage-auto-increase \
      --storage-auto-increase-limit=500 \
      --quiet
done

---

How to prevent it from happening again

Fixing the existing instances is the easy part. Keeping the setting on across every new instance your teams create is where the real value is. A few layers work well together.

Enforce it as policy with Terraform and CI gates

If all your Cloud SQL instances are defined in Terraform, add a check in your pipeline that fails the plan when disk_autoresize is not true. With Conftest and Rego you can write a policy against the Terraform plan JSON:

package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "google_sql_database_instance"
  resource.change.after.settings[_].disk_autoresize == false
  msg := sprintf("Cloud SQL instance %s must have disk_autoresize enabled", [resource.address])
}

Wire that into your CI so a pull request that disables autoresize never reaches apply.

Use Organization Policy where you can

GCP Organization Policy does not currently expose a dedicated constraint for storage auto increase, so treat policy-as-code in your IaC pipeline as the primary enforcement point. Pair it with a recurring scan so any instance created outside Terraform, through the console or an ad hoc gcloud command, still gets caught.

Monitor disk utilization regardless

Auto increase is a safety net, not a reason to stop watching. Set a Cloud Monitoring alert on the cloudsql.googleapis.com/database/disk/utilization metric so you get notified well before the disk approaches full, ideally around 80 percent. This gives you a chance to investigate abnormal growth, such as a runaway table, before automation papers over the symptom and the bill climbs.

---

Best practices

• Always enable automatic storage increase on production and staging instances. There is rarely a good reason to leave it off.
• Always set a growth limit. An unbounded auto increase protects availability but exposes you to cost surprises. Pick a limit that reflects realistic worst-case growth.
• Right-size the base disk anyway. Auto increase covers the unexpected, but starting with a sensible base size means fewer resize events and steadier performance, since IOPS scale with disk size on Cloud SQL.
• Alert on utilization trends, not just thresholds. A disk growing 5 percent per day tells you more than a single point reading. Trend alerts catch problems before they become incidents.
• Watch transaction log growth. Stuck replicas and replication lag are a common cause of unexpected disk consumption. Monitor replica health alongside disk usage.
• Test recovery. Know the runbook for manually increasing storage in case you ever hit an instance with auto increase still disabled, or one that has reached its configured limit.

Enabling automatic storage increase is one of the cheapest reliability improvements available on Cloud SQL. It costs nothing to turn on, applies without downtime, and removes an entire class of avoidable outages. Combine it with sensible limits, trend-based monitoring, and a policy gate in your pipeline, and running out of disk stops being a failure mode you ever have to think about.