Blue-Green deployment is a well-established release strategy for zero-downtime updates to online services and web applications. It lets teams release new application versions frequently, sometimes many times a day, without taking the service offline or making users aware that anything has changed.

But how easy is it to extend those same advantages to the database? A full-stack Blue-Green approach, where Blue and Green each have their own database, can work, but it introduces significant cost and complexity. This article focuses instead on shared-database blue-green database deployments, where there is a single production database and it must be updated in a way that it can support both the old ('blue') and new ('green') application versions simultaneously, until the 'blue' version is fully deprecated.

In other words, the key requirement is backward-compatible database changes. We’ll look at how this works using the Expand-Contract pattern, and how Flyway Enterprise helps make each stage of this strategy more controlled, visible, and reliable.

With this support in place, the same Flyway-managed database change process can support a range of phased rollout strategies, such as rolling deployments, canary releases, and ring deployments. The application rollout pattern may vary, but the database requirement is the same: old and new application versions must be able to run side by side safely during the transition window.

'Full stack' blue-green deployments

In application-tier Blue-Green deployments, you maintain two full application environments, or stacks. Blue hosts the live production version, Green hosts the release candidate. Once the release is approved, user traffic is switched from Blue to Green, generally all at once.

There are good reasons why this makes frequent online deployments much safer:

• Changes are more reliable – thoroughly test everything on green first
• Changes are easily reversible – if something goes wrong, re-route users to Blue
• Changes can be more controlled – app-tier blue-green can be extended to support staged switchovers of applications or users.

By extension, full-stack blue-green deployment means that Blue and Green each have their own application stack and database. In theory it carries the same advantages, but because databases are stateful, it comes with extra risk and complexity.

Once Green is ready to go live, the switchover is all-at-once, because only one database at a time should ever be writable. If you need gradual switchovers, it adds a lot of complexity (think: Kafka event streaming, or bidirectional replication).

Green must be kept current with changes to Blue right up to the point of switchover, which means data replication or log shipping. Finally, reversibility becomes more complex. Once users are accessing Green and writing new data, you cannot simply switch back to Blue without risking data loss, inconsistency, or corruption. Rollbacks still need careful planning.

Kellyn Gorman’s article, Best Practices for Blue-Green Database Deployments, covers the techniques and best practices for managing this type of full-stack Blue-Green database deployment and explains the role Flyway can play.

Shared database blue-green deployments

For organizations where the cost and challenges of running two parallel database environments make full-stack blue-green unviable, the alternative is the shared-database blue-green deployment strategy.

Here, Blue and Green application stacks run side by side, but both connect to the same production database. We no longer have full-stack isolation. This means that over the transition period when traffic switches from Blue to Green, we cannot make any breaking changes to the database; both application versions must continue to work normally.

Full-stack Blue-Green makes online database deployment safer in large part because of the ability to fully test green as a complete, isolated, parallel environment, before 'switching it on'. By contrast, the shared database blue-green strategy delivers better safely because it naturally supports a more controlled rollout of database changes.

With two complete application stacks (blue and green) and schema changes that are backward-compatible, we can phase in users and new features, shifting user traffic gradually from blue to green by customer group, tenant, region, or by progressively replacing application instances.

If teams have Flyway to generate, track and control backward-compatible schema changes, and manage the transition period, then shared database blue-green can deliver more frequent online database deployments that are safer and easily reversible.

The Expand-Contract pattern

The phased transition from blue to green is only safe if the shared database remains backward-compatible for as long as Blue and Green applications are both active. To achieve this, all schema changes follow the Expand-Contract pattern:

• Expand – backward-compatible database schema changes are made first, so that the database can support both application versions (blue+green) simultaneously, during the transition window.
• Contract – once all traffic is on Green, any schema structures implemented or retained only to support backward compatibility are removed.

Most deployments that use a phased rollout strategy for greater safety and control will rely on a database change management pattern such as Expand-Contract to ensure that the database can smoothly support the new features being rolled out, without "breaking contract" with existing older versions of the application. Many teams also use feature flags during the Expand phase, deploying the green code before the schema is fully expanded, but keeping the new feature switched off until the database is ready. This further decouples code deployment from the schema change, giving you an additional layer of control during the transition.

In the following shared-database blue-green deployment example, we have a single production database and use Flyway to make backward-compatible schema changes using Expand-Contract. In the transition phase, we progressively update application instances, perhaps a subset of Kubernetes pods serving a mobile app, from the 'blue' to 'green':

This phased switchover, progressively replacing old application instances with new ones, is typical of a rolling deployment strategy, but it could equally involve a targeted re-routing of user traffic as seen in canary releases, ring deployments, and other phased rollout patterns.

What Blue-Green adds over these other techniques is a separately deployed Green stack that can be verified before it takes traffic, plus a cleaner rollback route, moving users back to Blue if Green fails.

From a database change management perspective, however, they all depend on the same thing: backward-compatible schema changes that allow old and new application versions to run safely side by side. This means the Expand and Contract steps, however they are implemented, must be controlled, versioned, tracked and tested.

How Flyway supports safer online database deployments

The foundation for achieving safer online database deployments, whether blue-green, rolling or canary, is a technique called incremental refactoring, where we make small, frequent, well-tested and reversible changes to a database rather than 'big bang' migrations.

The book credited with popularizing it, Refactoring Databases by Ambler and Sadalage, is now over 20 years old but much of its advice still holds. What has changed is that tools like Flyway can now help teams deliver these patterns in a more controlled, repeatable and visible way.

For shared-database Blue-Green, the challenge is not simply running the required migrations to implement the schema changes, it is managing the whole Expand-Contract lifecycle: generating reviewing and testing the scripts, tracking exactly which objects changed and how, checking migration quality, and detecting drift to verify that the database remains in the expected state before, during and after the transition window.

Expand-Contract support

In the Expand phase, Flyway can generate and manage the migration scripts that introduce the new Green structures while preserving backward compatibility for Blue. Those migrations are versioned and tracked, so the team can see which compatibility objects were introduced, when, and as part of which change. Flyway Enterprise’s schema comparison and dependency-aware script generation can help identify object-level differences and produce migration or deployment scripts for review, rather than relying on hand-built scripts.

In the Contract phase, the cleanup work should also be handled as an explicit versioned undo migration. This is where objects needed only for backward compatibility are removed: proxy interface objects, synchronization logic, and old Blue versions of data structures. Flyway Enterprise will auto-generate these teardown scripts, and once checked and tested, it can execute them during a scheduled 'teardown'.

Object-level change tracking

Flyway Enterprise provides object-level change visibility through schema comparison and schema model support. This helps teams understand exactly what changed during the Expand phase and what still needs to be removed during Contract.

Its built-in drift detection is useful during and after the transition period. It can compare the production database with the expected schema and highlight unexpected differences, helping the team catch manual changes or leftover transition objects before they become permanent debris.

Database checks and tests

The temporary Blue+Green database state must be tested thoroughly against both application versions. It is not enough for Blue and Green simply to keep running; they must return consistent, expected results for routine business operations while they share the database.

Flyway can support this testing discipline by migrating test environments to the required Blue+Green schema state in a repeatable way. Automated checks and code review rules can be run as part of the build or deployment process, helping teams catch policy or quality issues before migration scripts reach production.

Flyway callbacks can also hook test or validation scripts into the migration lifecycle, for example after a successful migration. This gives teams a practical way to run their own SQL-based functional, unit and performance tests against the migrated database.

Shared-database Blue-Green vs rolling, canary and ring deployments

Once a team can deliver controlled, tracked and tested backward-compatible database changes, the same database discipline can support any phased rollout strategy.

Rolling deployments, canary releases and ring deployments only really differ in how they phase in the new application version, but they share the same database requirement: old and new application versions must be able to run safely side by side during the transition window.

Shared-database Blue-Green can use any of these phased rollout techniques. What it adds is the separate Green application stack: the new version can be deployed, checked and kept ready before production traffic is moved from Blue to Green.

Rolling deployments

In a typical rolling deployment of new application versions, there is only one application stack. We 'drain' connections from a subset of application instances, or 'pods', update them to green and bring them back into rotation, until eventually all pods are green. The risk is that updated instances usually start serving live traffic as soon as they return to the pool. If the new version has a problem, users may see it immediately, and fallback means rolling those instances back or forward again.

In a blue-green architecture, with two complete application stacks, we simply move traffic from blue pod 1 to green pod 1, then blue pod 2 to green pod 2, and so on. This gives us two advantages over pure rolling deployment.

1. Better verification of green – we can verify that green application instances are connected and function as expected before a single user is routed to them.
2. Rollback is instant and clean – if problems emerge, all traffic switches back to blue immediately, since the blue application stack remains untouched.

Canary releases and ring deployments

These phased or controlled rollout strategies, as well as others such as percentage rollouts, are all controlled ways to expose the new (green) software release to users in stages.

With a canary release, we deliberately target a very small subset of users (e.g., 5%). A ring deployment (often described as "multiple automated canaries") simply extends this idea, incrementally exposing the new version to defined groups of users, such as internal users, a named beta group, or a customer tier.

Each of these strategies will often incorporate feature flags to make it easier to toggle access to a new feature on or off, for specific user groups.

Database changes are managed using the Expand-Contract pattern, regardless. The following diagram illustrates how a typical canary release works, followed by a brief explanation of each stage.

1. Starting state: all user traffic is through blue app stack.
2. Expand schema: update the database from Blue to a temporary 'Blue+Green' state so it supports Green while still honoring the existing Blue 'contract'
3. Route canary traffic to green using load balancer or routing rules, and use feature flags where needed to control access to the new feature.
4. Validation complete – all user traffic to green
5. Contract: schema cleanup. The database moves from Blue+Green to Green.

In a Blue-Green architecture, canary and ring releases gain the same broad advantages as rolling deployments: better verification of Green before broad exposure, and a cleaner fallback route to Blue if Green must be withdrawn.

If the Green application uses feature flags, you can also deploy Green before exposing the feature that depends on the expanded schema. This decouples code deployment from feature release and gives the team another point of control during the transition.

Conclusion

The goal of blue-green database deployments is simple: we want the users to never even realize that a database upgrade happened in the background. For shared-database Blue-Green, achieving that means treating the database changes as carefully as the application release itself.

The database must first be expanded so that Blue and Green can both run safely against it. Traffic can then move to Green in a controlled way, using a phased rollout such as canary, rolling, or ring deployment. Once the Blue application is retired, the database is contracted to its final Green state.

Flyway Enterprise supports this lifecycle by making each database change controlled, visible and testable: generating and tracking migration scripts, showing object-level changes, applying checks, detecting drift and helping teams verify that the database remains in the expected state throughout the transition.

In the next article, we’ll look at the practical implementation choices for preserving backward compatibility during the transition window. These include using database abstraction techniques or maintaining old and new database structures side by side and keeping them aligned through application dual-writes or database synchronization techniques.