Achieving Zero‑Downtime Deployments with Database Schema Changes Using Flyway

Introduction

The article explores how to solve database compatibility and deployment challenges while achieving zero‑downtime releases. It assumes the goal of making backward‑compatible changes on a database that does not support native backward compatibility.

Zero‑Downtime Deployment Concept

Zero‑downtime deployment means updating an application to a new version in production without users noticing any outage. The article first presents a simple four‑step approach and then moves to a more realistic blue‑green deployment method.

Blue‑Green Deployment

Blue‑green deployment maintains two parallel production environments (blue and green) and switches traffic via URL mapping. This allows easy rollback by toggling the mapping, similar to flipping a switch.

Database Compatibility Challenges

When a new application version requires schema changes (e.g., renaming a column), the deployment must ensure both old and new versions can operate on the same database, otherwise zero‑downtime cannot be achieved.

Using Flyway for Versioned Migrations

The article uses Flyway as the schema version‑control tool in a Spring Boot project. Migration scripts are placed under classpath:db/migration. Example migration files are shown in the following image:

One of the scripts is V1__init.sql, which runs automatically on application startup if it has not been executed before.

Two Migration Strategies

Non‑backward‑compatible change (e.g., rename last_name to surname directly).

Backward‑compatible change (add new column, copy data, update code to use both columns, then drop the old column).

Non‑Backward‑Compatible Example

The article demonstrates a failing scenario where version 2.0.0.BAD renames the column without supporting the old version, leading to runtime exceptions for the 1.0.0 instance.

Steps:

Deploy a new instance with version 2.0.0.BAD and upgrade the database to v2bad (column renamed).

Old instance (1.0.0) still tries to write to last_name and crashes.

Rollback is impossible because the old code cannot operate on the new schema.

Log output is shown in the image below:

Backward‑Compatible Example

The article walks through four steps to rename the column safely:

Step 1 – Add new column : Deploy version 2.0.0, database version v2 adds surname and copies data from last_name. Both columns are written by the application.

Step 2 – Update code : Application version 2.0.0 reads from surname if not null, otherwise falls back to last_name. No NOT NULL constraint is added to surname.

Step 3 – Remove old column usage : Deploy version 3.0.0, stop writing to last_name, keep data in surname.

Step 4 – Drop old column : Deploy version 4.0.0, database version v4 drops last_name and adds any needed constraints.

Key warnings are highlighted: the new column must not have a NOT NULL constraint, and the old getter method ( getLastName()) must be removed or guarded.

Images illustrating each migration step are included:

A/B Testing and Rollback

The article shows how A/B testing can be performed when both versions run against the same database version (e.g., v2). It also details rollback procedures for each step, emphasizing that rollback is safe only when the schema change is backward compatible.

Running the Examples

All example code is available in a GitHub repository (a Spring Boot Flyway sample). The article provides commands to run the backward‑compatible and non‑backward‑compatible scenarios, as well as URLs to view the H2 console and Flyway UI.

Conclusion

By following the backward‑compatible migration pattern—adding a new column, copying data, updating code to use both columns, and finally dropping the old column—teams can achieve zero‑downtime deployments even for schema changes that are not natively backward compatible.