Zero-Downtime Database Upgrades with Blue-Green Deployments

Database upgrades are the kind of task that sounds simple until you remember what is at stake. A botched upgrade means downtime, and downtime means lost revenue, broken trust, and on-call engineers reading logs at 3 AM. Rolling updates help, but they still mutate your live environment in place. Blue-green deployments take a fundamentally different approach: build the new environment first, verify it works, then switch traffic over in one atomic step.

FoundryDB supports blue-green deployments as a first-class maintenance operation. You can validate prerequisites, provision a parallel green environment, let replication sync the data, and switchover when you are confident. If something goes wrong before or after the switch, you roll back.

Why Blue-Green Instead of Rolling Updates

Rolling updates upgrade one node at a time within your existing cluster. They work well for minor version bumps and configuration changes, and FoundryDB supports them with pause/resume controls. But rolling updates have limitations:

	Rolling Update	Blue-Green Deployment
Downtime	Brief failover (~60s) during primary promotion	Zero, DNS cutover is atomic
Validation	No pre-switch validation on the target version	Full validation before switchover
Rollback	Must re-upgrade nodes already changed	Instant, traffic returns to original environment
Resource cost	No extra VMs	Temporary second environment (cleaned up after)
Best for	Config changes, minor version patches	Minor version upgrades, VM replacement, zero-downtime maintenance

The tradeoff is straightforward. Blue-green costs more during the transition (you are running two environments), but gives you a safety net that rolling updates cannot match. For production databases where even a 60-second failover is unacceptable, blue-green is the right choice.

How It Works on FoundryDB

A blue-green deployment on FoundryDB follows a six-state lifecycle:

Running → BlueGreenCreating → BlueGreenSyncing → BlueGreenReady → BlueGreenSwitching → BlueGreenCleaning → Running

1. Creating. FoundryDB provisions a new "green" VM with the target database version. Same compute plan, same storage tier, same configuration as your live "blue" environment.
2. Syncing. Streaming replication starts from blue to green. All writes to the blue environment are continuously replicated to the green environment.
3. Ready. Once replication lag drops below your configured threshold (default: 5000 ms), the deployment enters the ready state. You can now inspect the green environment and run validation queries.
4. Switching. You trigger the switchover. DNS records update to point to the green environment. This is atomic: your connection strings do not change.
5. Cleaning. The old blue environment is retained briefly for rollback, then automatically cleaned up.
6. Running. The service returns to normal operation on the new environment.

At any point before the switchover completes, you can roll back. Traffic returns to the original blue environment and the green environment is torn down.

Step 1: Validate Prerequisites

Before starting a deployment, check whether your service supports blue-green for the target version. The validate endpoint returns a clear pass/fail result with specific error messages if something blocks the deployment.

curl -u user:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/blue-green/validate \
  -H "Content-Type: application/json" \
  -d '{"target_version": "17.7"}'

A successful validation returns:

{
  "valid": true,
  "warnings": [],
  "errors": [],
  "current_version": "17.3",
  "target_version": "17.7",
  "database_type": "postgresql",
  "upgrade_type": "minor",
  "replication_mode": "streaming"
}

The validation checks four things: that your service is in Running state, that no other maintenance operation is already active, that the version increment is sequential (no skipping, e.g., 15 to 17), and that the database engine supports the deployment type.

Known limitation: Major version blue-green (e.g., PostgreSQL 16 to 17) is not yet supported for PostgreSQL and MySQL. Streaming replication cannot work across major versions due to WAL/binlog format incompatibility. Logical replication support is planned for a future release. For major version upgrades on these engines, use the in-place pg_upgrade or mysql_upgrade paths instead.

Step 2: Create the Deployment

Once validation passes, create the blue-green deployment:

curl -u user:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/blue-green \
  -H "Content-Type: application/json" \
  -d '{
    "target_version": "17.7",
    "replication_lag_ms": 5000
  }'

The response returns a deployment ID and confirms the service is transitioning:

{
  "id": "6fa85f64-5717-4562-b3fc-2c963f66afa6",
  "service_id": "a1b2c3d4-...",
  "status": "in_progress",
  "target_version": "17.7",
  "replication_lag_ms": 5000,
  "created_at": "2026-04-06T14:30:00Z"
}

The replication_lag_ms parameter controls how close the green environment must be to the blue environment before the deployment is considered ready for switchover. Lower values mean tighter consistency but may take longer to stabilize under heavy write loads. The minimum is 100 ms.

You can also schedule deployments for a future maintenance window by adding scheduled_at:

curl -u user:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/blue-green \
  -H "Content-Type: application/json" \
  -d '{
    "target_version": "17.7",
    "replication_lag_ms": 1000,
    "scheduled_at": "2026-04-10T02:00:00Z"
  }'

Step 3: Monitor and Validate

Poll the deployment status to track replication progress:

curl -u user:password \
  https://api.foundrydb.com/managed-services/{id}/blue-green/{deployment-id}

Once the status shows ready (the BlueGreenReady state), the green environment is fully synced. This is your window to run any validation you need: connect to the green service, run test queries, verify that your application logic works against the new version.

Step 4: Switchover

When you are satisfied that the green environment is correct, trigger the switchover:

curl -u user:password -X PUT \
  https://api.foundrydb.com/managed-services/{id}/blue-green/{deployment-id}/switchover

The service must be in BlueGreenReady state. If it is not (for example, if replication has not caught up), the API returns a 409 Conflict with the current state.

After switchover, DNS records are updated to point to the green environment. Your application's connection strings remain the same. The old blue environment is retained briefly, then cleaned up automatically.

Rollback

If something goes wrong before or after the switchover (but before cleanup completes), roll back:

curl -u user:password -X PUT \
  https://api.foundrydb.com/managed-services/{id}/blue-green/{deployment-id}/rollback

Traffic re-points to the original blue environment and the green environment is torn down. Rollback is not available after the deployment reaches completed or cancelled status.

To cancel a deployment that has not yet switched over (for example, if you decide not to proceed during the validation phase), use the cancel endpoint instead:

curl -u user:password -X DELETE \
  https://api.foundrydb.com/managed-services/{id}/blue-green/{deployment-id}

This cleans up the green environment and returns the service to Running.

When to Use Each Strategy

Use rolling updates when:

• Applying configuration changes across your cluster
• Performing minor version patches on multi-node services
• You can tolerate a brief failover (~60 seconds) during primary promotion
• Minimizing temporary resource cost matters

Use blue-green deployments when:

• Zero downtime is a hard requirement
• You want to validate the target version before committing
• You need the ability to roll back instantly after switchover
• You are performing same-version maintenance (VM replacement, OS patching via a fresh environment)

Both strategies are available for the same service. You can use rolling updates for routine patches and reserve blue-green for higher-stakes upgrades.

Get Started

Blue-green deployments are available on all FoundryDB database engines that support streaming replication: PostgreSQL, Valkey, MongoDB, and Kafka. Start by validating your target version, then create your first blue-green deployment.

Read the full Maintenance & Upgrades documentation for details on maintenance windows, rolling updates, and version upgrade paths. Or create a free FoundryDB account and try it on a test service.