Moving from MySQL 8.0 to 8.4 on Cloud SQL no longer has to mean a multi-hour maintenance window at 2 a.m. on a Saturday. Since October 28, 2026, Cloud SQL for MySQL offers managed blue-green deployments in preview: an upgraded copy that stays in sync with production, can be tested with real traffic, and takes over in seconds without changing the instance's IP address or name. Amazon RDS has had the same thing since November 2022.
What changes
Until now, a major version upgrade on Cloud SQL was in place: the instance went down while it upgraded, and if something broke, rolling back meant hours of restoring from backup. Blue-green splits the job into three phases:
- Blue: the production instance keeps serving traffic without interruption.
- Green: Cloud SQL creates a temporary clone, upgrades it to the target version and keeps it current through continuous replication. You can point real queries and application traffic at it; if something looks off, you delete the deployment without touching production.
- Switchover: Cloud SQL briefly puts blue into read-only mode, finishes the final sync and promotes green to primary. The IP address, instance name and backups move over to green, so connection strings stay the same.
The old blue instance sticks around as a manual fallback until you delete it. The feature covers major version upgrades and configuration changes on standalone MySQL primary instances, including high-availability setups. Google says PostgreSQL support is coming.
How to run it
Besides the console, the whole cycle is available in gcloud. These are the commands from the announcement for an 8.0 to 8.4 upgrade:
# Create the upgraded, synced green environment
gcloud sql blue-green-deployments create my-upgrade \
--source-instance=prod-mysql-db \
--target-database-version=MYSQL_8_4
# Check status and get the test endpoint
gcloud sql blue-green-deployments describe my-upgrade \
--region=us-central1
# Connect to the upgraded copy and test it
gcloud sql connect TARGET_INSTANCE_NAME --user=admin
# Move production traffic to green
gcloud sql blue-green-deployments switchover my-upgrade
# Delete the old blue once you no longer need it
gcloud sql blue-green-deployments delete my-upgrade \
--region=us-central1 \
--delete-old-sourceThe step between describe and switchover is what makes this worthwhile: point a staging environment or a replay of your workload at green and compare query plans, latency and errors on the new version before any customer notices.
Cloud SQL vs. Amazon RDS
| Cloud SQL (MySQL) | Amazon RDS / Aurora | |
|---|---|---|
| Status | Preview, since Oct 28, 2026 | GA since Nov 27, 2022 |
| Engines | MySQL; PostgreSQL announced | Aurora MySQL, RDS for MySQL, RDS for MariaDB (at launch) |
| Stated cutover | "In seconds" | "As fast as a minute" |
| Endpoint | Keeps IP, name and backups | No application code changes |
| Safety net | Delete green before switchover | Guardrails cancel the switchover past a timeout |
| Green environment cost | Not detailed in the announcement | Billed like any other instance |
Google is four years late, but with one point in its favor: carrying over the IP and name means no changes to secrets, internal DNS or Cloud SQL Auth Proxy config. RDS, in turn, has maturity and guardrails that abort the switchover if it would take longer than you allow; the Cloud SQL announcement mentions nothing equivalent.
Gotchas and edge cases
- The read-only window is real. Even if it lasts seconds, writes fail during switchover. Make sure your app retries writes and that no critical job (queues, billing cron) runs during the cutover.
- Rollback isn't symmetric. Before switchover, cancelling is free. After it, the old blue is only a manual fallback: writes that already landed on green aren't in it.
- Two instances at once. Green is a full clone of blue, so while you test you're running double the capacity. Keep test windows short and don't forget the
deletewith--delete-old-source. - It's a preview. For a critical database, rehearse the full cycle on a staging instance first.