When would you actually prefer blue-green deployment over canary, even for a system where reliability is critical?

Blue-green wins when the system can't safely run two versions concurrently at all (making canary's gradual traffic-split fundamentally unsafe, not just slower), when a fast, clean, all-or-nothing rollback matters more than gradual exposure, or when the operational simplicity of a single binary cutover is worth more than canary's more complex traffic-splitting and metric-comparison infrastructure — canary's blast-radius advantage only helps if partial exposure is actually a safe, meaningful state for the system to be in.

Canary's core value proposition — limit exposure to a fraction of traffic while validating the new version — depends on partial exposure being a safe, coherent state. That assumption doesn't hold universally:

Systems that can't safely run two versions concurrently: if old and new versions can't coexist correctly (an incompatible wire protocol between coordinating instances, a shared resource that only one version can safely manage at a time, certain stateful systems where mixed-version operation genuinely isn't supported), canary's whole premise — some users on the old version, some on the new, simultaneously — is unsafe regardless of how small the canary percentage is. Blue-green's clean, complete cutover from one full environment to another avoids ever having mixed versions coexist in the first place.

When rollback speed and simplicity matter more than gradual validation: blue-green rollback is typically a single, fast, well-understood action (flip traffic back to the still-running old environment), whereas canary rollback involves winding down a partial, possibly-multi-stage traffic shift — for a system where "roll back instantly and completely, no ambiguity" is the priority over "gradually validate and minimize exposure," blue-green's simpler failure mode is worth more.

Lower operational complexity for teams without canary tooling maturity: canary deployments done well require real infrastructure — traffic-splitting capability, metric comparison against a live baseline, automated promotion/rollback logic (per the earlier metrics-and-thresholds design). A team without that infrastructure built out yet, deploying a system where blue-green's simpler safety model (full environment swap, fast rollback) is sufficient for the actual risk profile, may reasonably prefer blue-green rather than building canary infrastructure just because it's generally considered more sophisticated.

Lower-traffic systems where canary's statistical benefit is weak: canary's gradual validation relies on getting a statistically meaningful signal from the partial traffic it receives — for a genuinely low-traffic system, a small canary percentage might not generate enough data to validate anything meaningfully faster than just watching the full cutover closely would, making canary's added complexity not worth its diminished statistical benefit.

The broader point: canary being the generally-recommended default doesn't mean it's universally better — it's better specifically when partial, gradual exposure is both safe and statistically useful, and worse than blue-green's simplicity when those conditions don't hold.

• Canary's safety advantage only applies when partial exposure (mixed old/new versions running concurrently) is actually a safe, coherent state — not every system can support that.
• Blue-green's single, fast, well-understood rollback can be preferable when rollback simplicity matters more than gradual validation.
• Canary requires real traffic-splitting and metric-comparison infrastructure; blue-green's simpler model may be the right trade-off for teams without that maturity yet.
• Low-traffic systems get diminished statistical benefit from canary's gradual exposure, making its added complexity less worthwhile.

• Martin Fowler: BlueGreenDeployment
• Martin Fowler: CanaryRelease