Cloud SQL instances averaging under 10% CPU that fit one tier smaller
What does ZopNight detect here?
Cloud SQL bills for the vCPUs and memory of the instance's machine type whether or not queries use them. ZopNight flags instances whose `database/cpu/utilization` averaged under 10% over 30 days, picks the next-smaller tier that still covers observed peak CPU, and prices the move from live rates for both tiers.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-113 |
| Category | rightsizing |
| Severity | high |
| Metric | database/cpu/utilization |
| Threshold | average CPU under 10% |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | cloudsql.instances.list · cloudsql.instances.get · monitoring.timeSeries.list |
Where it applies
Idle vCPUs in a database tier still bill every hour
A Cloud SQL instance pays for its machine shape: vCPUs and memory, per the Cloud SQL pricing page, around the clock while it runs. Databases are commonly sized for a launch estimate or a one-off migration and never revisited, so it is normal to find a tier whose CPU spends the month in single digits.
Measuring CPU on your instances
List instances with their tier, then chart CPU for a candidate:
gcloud sql instances list --format="table(name,databaseVersion,settings.tier,state)"In Metrics Explorer, use cloudsql.googleapis.com/database/cpu/utilization, a fraction of
reserved CPU that is currently in use, over the last 30 days. Look at both the average and the
peaks, and chart database/memory/utilization next to it.
The CPU gate and the target tier
ZopNight reads 30 days of CPU and fires when the average is under 10%. The downsize target is the next-smaller tier in the same family, chosen so observed peak CPU still fits: a quiet average with tall peaks can rule out a move entirely. The saving is priced from live per-tier rates, and moves that save less than 5% or more than 85% of the current rate are treated as suspect and dropped.
Tiers and cases it cannot evaluate
The tier ladder covers the predefined db-n1-standard and db-n1-highmem families. Custom
db-custom shapes, Enterprise Plus db-perf-optimized shapes and the shared-core
db-f1-micro and db-g1-small floor have no ladder, so those instances are not scored. ZopNight
also stays silent when either tier’s rate is missing, or when the instance is already on the
smallest tier. When memory utilization data is present and high, it vetoes the downsize.
Rate difference between the two tiers
fraction = 1 - (target tier rate / current tier rate)saving = current monthly cost x fractionDownsizing a Cloud SQL instance
ZopNight advises this change but does not apply it, because database sizing is the DBA’s call.
- Review CPU and memory together; a memory-bound workload may need the same memory at fewer vCPUs.
- On Enterprise edition dedicated-core instances, set CPU and memory directly, for example
gcloud sql instances patch INSTANCE_NAME --cpu=2 --memory=7680MiB. Enterprise Plus uses--tier. - Schedule it in a quiet window: the gcloud reference warns the instance will be restarted.
- Watch query latency for a week and move back up if needed.