The Idea
Blue green deployment keeps two environments: blue is live, green is the new one. For databases the green is a copy kept in sync with blue via replication. At cutover you switch the application to green. If something is wrong, you switch back. The appeal is a fast, reversible flip rather than a long maintenance window.
The Hard Part Is State
Stateless apps swap trivially, but a database holds state that keeps changing. The challenges are:
- Keeping green current: replicate blue into green continuously until the moment of cutover.
- The cutover gap: at the switch, in flight writes must stop on blue and resume on green without loss. This usually means a brief write freeze or a careful handoff at a replication position.
- Rollback writes: once green takes writes, blue is behind. To roll back safely you need reverse replication from green to blue, or you accept losing the writes made on green.
When To Use It
Blue green cutover shines for risky upgrades, like a major version bump, where you want to validate green under real config and bail out quickly. The cost is running two full databases and engineering the synchronization both ways.
Key idea
Blue green database cutover runs a synced standby beside the live database for a fast reversible switch, but the moving state makes the cutover handoff and reverse replication for rollback the genuinely hard parts.