Blue-Green vs. Canary: Picking a Rollout Strategy

Blue-green deployment keeps two full production environments and switches traffic between them atomically, which makes rollback nearly instant — you just flip the router back — but it means bad state introduced by the new version (a broken cache, a bad migration) can't be limited to a subset of traffic; it's all-or-nothing. Canary deployment routes a small percentage of real traffic to the new version first, which limits blast radius by letting you catch a regression before it reaches everyone, but rollback is slower (you have to drain and redeploy) and you need real traffic-based metrics and automated rollback thresholds to make it safe, not just a person watching a dashboard. Use blue-green when a change is high-confidence but needs instant rollback capability (a config change, a well-tested feature flag flip). Use canary when the change itself is the uncertain part — a new algorithm, a dependency upgrade, a database query rewrite — where you specifically want production traffic to validate correctness before full exposure. Database migrations complicate both: a migration that isn't backward-compatible with the previous version breaks blue-green's instant-rollback guarantee and breaks canary's mixed-version guarantee simultaneously, which is why expand-contract migration patterns exist independently of which rollout strategy you use.