Skip to content

AWS Updated 2026-07-04

RDS blue/green deployments: near-zero-risk engine upgrades and schema changes

How RDS blue/green deployments work, what the switchover actually does, and the runbook for using them to ship engine upgrades and schema changes with about a minute of interruption.

An RDS blue/green deployment creates a fully synchronized copy of your production database (the green environment), lets you upgrade or modify the copy while production keeps serving traffic, then swaps the two in a switchover that typically completes in under a minute. Your endpoints do not change — RDS renames the instances underneath them — so applications reconnect to the new environment without a config change. It is the closest thing RDS has to a low-drama major version upgrade.

What’s happening

When you create a blue/green deployment, RDS clones the topology of the blue (production) environment — primary, replicas, parameter groups — and keeps green in sync using replication: binary log replication for MySQL and MariaDB, logical replication for PostgreSQL, and the same mechanisms on the Aurora variants. Blue/green is available for RDS MySQL, MariaDB, and PostgreSQL, and for Aurora MySQL and Aurora PostgreSQL — not for Oracle or SQL Server.

Green is where you do the risky work: a major engine version upgrade, a parameter change that needs a reboot, an instance class change, a storage change, or schema changes such as adding indexes. Because green is a live replica of blue, you can test against production data without touching production.

Switchover is the part worth understanding. RDS runs guardrails first: it checks replication lag, blocks new writes on blue, waits for green to catch up fully, then renames the environments so that the existing endpoints point at green. If the guardrails cannot complete inside the switchover timeout you set (30 to 3,600 seconds, default 300), the switchover rolls back and blue keeps serving — that failure mode is an inconvenience, not an outage. After a successful switchover the old blue instances survive with an -old1 suffix, still holding data as of the switchover, until you delete them.

Two honest caveats. First, on PostgreSQL, logical replication does not carry DDL: schema changes made on blue after the green environment exists do not flow to green, so you freeze schema changes for the life of the deployment. Second, green is writable — writing to it outside of the intended change (the engine upgrade itself, index builds) can break replication and invalidate the whole exercise. The full prerequisites per engine are in the RDS documentation at https://docs.aws.amazon.com/rds/.

What to check first

  • Engine eligibility — MySQL, MariaDB, PostgreSQL, Aurora MySQL, Aurora PostgreSQL only, on supported versions.
  • PostgreSQL logical replication prerequisites — rds.logical_replication = 1 on the source, which requires a reboot if not already set, and tables generally need primary keys.
  • External replication consumers — binlog readers (Debezium, ETL) and self-managed replicas attached to blue need a plan for the switchover.
  • Long-running transactions — anything holding a transaction open at switchover time eats into the timeout budget.
  • DNS caching in the application — the endpoint name survives, but clients that cache resolved IPs beyond the TTL will reconnect to the wrong side.

How to verify

Create and inspect a deployment:

aws rds create-blue-green-deployment \
  --blue-green-deployment-name prod-pg16-upgrade \
  --source arn:aws:rds:ca-central-1:123456789012:db:prod-db \
  --target-engine-version 16.4 \
  --target-db-parameter-group-name prod-pg16-params

aws rds describe-blue-green-deployments \
  --query 'BlueGreenDeployments[].[BlueGreenDeploymentName,Status,SwitchoverDetails]'

Watch replication health before you even think about switching: in the console, RDS > Databases shows the green instances nested under the blue/green deployment, and the green primary’s Monitoring tab exposes ReplicaLag (MySQL) or OldestReplicationSlotLag (PostgreSQL). Lag should be seconds and stable, not sawtoothing.

aws cloudwatch get-metric-statistics --namespace AWS/RDS \
  --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=prod-db-green-abc123 \
  --start-time 2026-07-04T12:00:00Z --end-time 2026-07-04T14:00:00Z \
  --period 300 --statistics Maximum

The runbook

  1. Prepare the target configuration first. New-family parameter group with your customizations ported, target engine version, any instance class change. Blue/green applies these at green creation, not at switchover.
  2. Create the deployment during quiet hours. Initial green creation copies the full dataset; on large instances this takes hours. Production is unaffected but replication start-up load is real.
  3. Validate green like a staging environment. Connect directly to the green endpoints (they exist, with generated names), run EXPLAIN on your worst queries, run migrations rehearsals, check extension versions. Do not write application data to green.
  4. Freeze schema changes and heavy batch jobs. On PostgreSQL especially, DDL on blue does not replicate. Pause deploy pipelines that run migrations.
  5. Switch over with a deliberate timeout. aws rds switchover-blue-green-deployment --blue-green-deployment-identifier bgd-xxxx --switchover-timeout 300. Pick a low-traffic window; the write-block phase is where user-visible errors happen, and it is usually well under a minute.
  6. Verify, then clean up. Confirm application health and that writes land on the new environment, keep the -old1 instances for a defined grace period (they are your rollback data), then delete the deployment and the old instances to stop paying for them.

When this is the wrong move

For a minor version bump or a parameter tweak that tolerates a maintenance-window blip, blue/green is overkill — you are paying for a full duplicate environment for days. It is also unavailable for Oracle and SQL Server, and awkward when external binlog consumers cannot tolerate the topology swap. And it does not replace a real high-availability design: switchover is planned, failover is not, and Multi-AZ still owns the unplanned case. Rollback after switchover is also not a button — old blue is a data snapshot in time, and writes that landed on green after switchover exist only on green.

Common mistakes

  • Writing to green before switchover and silently breaking replication — the guardrails then refuse to switch and the deployment must be recreated.
  • Running schema migrations on blue mid-deployment on PostgreSQL, leaving green with a divergent schema.
  • Forgetting the storage cost of the duplicate environment — green is a full copy of instances and storage, billed normally for its lifetime.
  • Treating old blue as a live fallback weeks later, when it is frozen at switchover time and drifting further from reality every day.

Prevention

  • Rehearse the whole cycle once on a non-production database so the first production switchover is not the first switchover.
  • Keep parameter groups and target versions in infrastructure-as-code so green creation is reproducible.
  • Alarm on replica lag for the green environment during the deployment window.
  • Time-box the deployment: create, validate, switch, clean up inside a week, so duplicate-environment cost stays a rounding error.

Used with that discipline, blue/green turns the scariest RDS operations — major engine upgrades above all — into a minute of controlled interruption instead of an open-ended maintenance window. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.