Explanation
Why the waste happens and who it affects.
The surcharge is added on top of normal instance pricing for every second the instance runs. Instances on MySQL 5.6 and 5.7 and PostgreSQL 9.6 through 12 have been in extended support since February 1, 2025, and PostgreSQL 13 since February 1, 2026. MySQL 8.0 enters extended support on January 1, 2027 and PostgreSQL 14 on February 1, 2027.
Because enrollment needs no action, the charge often goes unnoticed until it shows up on the bill, and it applies equally to production, replicas, dev and test instances that nobody plans to upgrade. The surcharge also rises over time: the published extended support rate for year 3 is double the rate for years 1 and 2. When extended support ends (February 1, 2028 for MySQL 5.6 and 5.7 and PostgreSQL 9.6 to 12), Cloud SQL deprecates the version and upgrades remaining instances to the default major version automatically, so delaying the upgrade only means paying more before an unplanned upgrade.
Billing model
The pricing dimensions that drive this cost.
Extended support is charged in addition to regular instance pricing and varies by region.
- Dedicated-core extended support
- Priced per vCPU per hour and charged for every second the instance runs
- Shared-core extended support
- Priced per instance per hour for db-f1-micro and db-g1-small
- HA and read replicas
- HA instances pay the HA extended support rate, and read replicas are charged at the same rate as stand-alone instances
- Year 3 rate
- The published year 3 extended support price is twice the year 1 and year 2 price
- No CUD coverage
- Committed use discounts do not apply to extended support prices
How to detect
4 checks to find it in your estate.
- Use the Type filter on the Cloud SQL Instances page to select EOL versions, or Database Center with EOL versions selected under Products and versions for an organization-wide view
- List databaseVersion for all instances (gcloud sql instances list) and compare against the Cloud SQL database version policies, including upcoming dates for MySQL 8.0 (January 1, 2027) and PostgreSQL 14 (February 1, 2027)
- Look for extended support SKUs in the Cloud Billing export to BigQuery and attribute them to instances and projects
- Prioritize by vCPU count and HA configuration, since the surcharge scales with vCPUs and HA doubles it
How to fix
5 ways to remove the waste.
- Upgrade in place with gcloud sql instances patch INSTANCE --database-version=VERSION; Cloud SQL takes pre-upgrade and post-upgrade backups automatically, and the instance is unavailable during the upgrade (typically under 10 minutes, longer for large instances)
- Upgrade read replicas before the primary, or include them with --include-replicas-for-major-version-upgrade
- Test the upgrade on a clone or in non-production first to catch incompatible SQL, extensions or client drivers
- Delete or consolidate idle and non-production instances on EOL versions instead of upgrading them
- Plan MySQL 8.0 and PostgreSQL 14 upgrades now so they finish before their extended support start dates
Documentation
Vendor references for pricing and configuration.