Upgrade AWS Databases

Sometimes database components like Postgres and Mysql need to be upgraded as your application scales.

When you change fields like version or instance, SST applies the update on the next sst deploy.

By default, AWS performs the upgrade in place. This restarts the database and causes temporary downtime until your application can reconnect.

This guide covers the different strategies to minimize that downtime.

---

Multi-AZ

Postgres and Mysql support Multi-AZ deployments. AWS maintains a standby replica in a different availability zone. During the upgrade, changes are applied to the standby first, then it fails over. This reduces downtime to around 60-120 seconds instead of the full upgrade duration.

sst.config.ts

const database = new sst.aws.Postgres("MyDatabase", {
  vpc,
  version: "17",
  multiAz: true,
});

Multi-AZ roughly doubles the cost since a standby instance is always running. You can enable it temporarily for the upgrade and disable it after.

Caution

Major version upgrades restart both instances, making Multi-AZ ineffective for reducing downtime.

Enabling RDS Proxy through the proxy property can help further reduce failover downtime by detecting the new primary directly instead of waiting for DNS propagation. This can bring downtime down to just a few seconds.

---

Blue/Green

Postgres and Mysql support AWS RDS Blue/Green deployments through the blueGreen property. This creates a staging copy of your database, applies the changes there, and switches over with near-zero downtime.

sst.config.ts

const database = new sst.aws.Postgres("MyDatabase", {
  vpc,
  version: "17",
  blueGreen: true,
});

Your database endpoint stays the same throughout, so no application changes are needed. The overall deploy takes significantly longer but actual downtime is near zero.

Caution

Blue/Green deployments are not compatible with databases that have read replicas or proxy enabled.

Learn more in this Pulumi article.

---

Upgrading steps

Here’s the recommended workflow for upgrading a production database.

1. Check compatibility

Not all version jumps are allowed. You might need to go through intermediate versions.

• PostgreSQL upgrade paths
• MySQL upgrade paths
• Aurora PostgreSQL upgrade paths
• Aurora MySQL upgrade paths

2. Pick a strategy

Use in-place if some downtime is fine, Multi-AZ to reduce it, or Blue/Green for the shortest switchover when supported.

Component	In-place	Multi-AZ	Blue/Green
Postgres	✓	✓	✓
Mysql	✓	✓	✓
Aurora	✓	✕	✕
Redis	✓	✕	✕
OpenSearch	✓	✕	✕

3. Verify in a test stage

Apply the change in a test stage first to ensure the upgrade works as expected.

sst.config.ts

const database = new sst.aws.Postgres("MyDatabase", {
  vpc,
  version: "16",
  version: "17",
  blueGreen: true,
});

4. Deploy to production

Finally, deploy the upgrade to your production stage.

sst.config.ts

const database = new sst.aws.Postgres("MyDatabase", {
  vpc,
  version: "17",
  blueGreen: true,
});