# GCP Cloud SQL Right-sizing

> Cloud SQL instances averaging under 10% CPU across 30 days are carrying a larger tier than the workload needs. ZopNight picks the next-smaller tier from the machine catalog, prices the move from live SKU rates, and leaves the resize itself to your DBA; it never mutates customer databases.

Source: https://zop.dev/integrations/gcp/recommendations/gcp-cloud-sql-right-sizing
Updated: 2026-08-19

---

## A 10% average is the trigger

Databases get sized for launch-day fears, then run for years at a fraction of that. The
rule reads `CloudSQLCPUUtilization` over 30 days and fires when the average sits below
10%. Such an instance barely touches its CPU while the tier bills for every provisioned
core. The metric arrives through `monitoring.timeSeries.list`
(`roles/monitoring.viewer`); a memory-pressure veto exists so an instance that is
CPU-quiet but memory-bound is not downsized out of its RAM.

## The target must exist in the catalog

"Use a smaller tier" is not actionable advice, so the rule walks the Cloud SQL machine
ladder and names a concrete next-smaller tier, using the full-series peak as a
conservative stand-in for p95: a windowed slice is never allowed to hide an older spike
and pick a too-aggressive tier. The saving is the real rate difference between the two
tiers, 1 − target/current, applied to the instance's monthly cost. Rate deltas outside a
5%–85% sanity band are discarded as probable catalog mismatches rather than shipped.

## Why ZopNight will not resize it for you

Database tier changes restart the instance and sit squarely in DBA territory, so this
recommendation is advisory by policy: ZopNight never mutates customer database tiers on
any cloud. The remediation is guidance for the team that owns the change window. Pick a
current-generation Enterprise tier or a db-custom shape sized to observed CPU and memory,
and avoid the legacy shared-core tiers.

## Confirm the tier and the CPU curve

```bash
gcloud sql instances describe my-instance \
  --format="value(settings.tier,settings.availabilityType)"
```

Then open Cloud Monitoring and check both average and p95 CPU for the same 30-day window
before scheduling the resize.

## Cases the rule refuses to price

No recommendation is produced for stopped instances, when the CPU metric is absent, when
memory utilization is recorded at 60% or higher, when cost is unknown, when no provably
smaller tier exists (already-smallest tiers, db-custom shapes, and the shared-core floor
all end the walk), or when either SKU rate is missing, inverted, or out of band. The old
fallback that guessed 50% of cost is gone; every figure shown is backed by a real rate
pair.