Comparisons
Pairs that get conflated in real conversations, and a few that get treated as synonyms when one is a prerequisite for the other. Neither column wins — what decides is the change in front of you. Each record leads with the confusion, because the confusion is why the record exists.
Blue/Green vs Canary
They are treated as two flavours of "safe deploy", but they answer different questions. Blue/green optimises the speed of reversal and does nothing to limit exposure — at cutover, one hundred percent of users get the new version. Canary limits exposure and does nothing to make reversal instant for the users already on it. The second confusion is cost and state: blue/green needs double the capacity for the overlap and both environments share the database, so schema compatibility is still mandatory. "We do blue/green, so we do not need backward compatibility" is a common and expensive mistake.
Use blue/green when you want an instant, complete switch to a fully warmed environment and an instant way back.
Use canary when you want a small fraction of real traffic to test a hypothesis about the new version before the rest is exposed.
| Dimension | Blue/green | Canary |
|---|---|---|
| Exposure during rollout | Zero, then everyone | A defined slice, then more |
| Reversal | Switch traffic back to the environment still running | Remove the canary, which was always a minority |
| Capacity cost | Roughly double during the overlap | Marginal — a few extra instances |
| What it detects | Failures visible immediately after full cutover | Failures that show up as a statistical difference against a baseline |
| Shared state | Both environments hit the same database — compatibility still required | Both versions hit the same database — compatibility still required |
| Weak against | Slow-burn failures discovered after the old environment is torn down | Rare failures that a small slice will not surface in the observation window |