Infrastructure Comparisons
Side-by-side trade-offs where neither column wins. The workload, the team and the operational budget decide — and each comparison ends with the verdict that follows from that, not from a preference.
VM vs Container vs ServerlessManaged vs self-hosted databaseObject vs block vs file storageRolling vs blue/green vs canaryActive-passive vs active-activeDeclarative vs imperative infrastructure
Rolling vs blue/green vs canary
Every deployment strategy trades rollout speed, rollback speed, capacity cost and how much traffic a bad release reaches before you notice.
| Dimension | Rolling | Blue/green | Canary |
|---|---|---|---|
| Capacity during deploy | Same fleet, reduced briefly | Double | Same plus a small extra slice |
| Rollback speed | Another rolling pass | Instant — switch traffic back | Instant for the canary slice |
| Both versions live at once | Yes | Only during the switch | Yes, deliberately |
| Backward compatibility required | Yes | For the switch window | Yes |
| Traffic a bad release reaches | Grows as the rollout proceeds | All of it, at the switch | A controlled slice |
| Needs good metrics | Helpful | Helpful | Required — otherwise it is just a slow deploy |
| Database migrations | Must be compatible with both versions | Do not switch with the traffic | Must be compatible with both versions |
Use Rolling when
- The default for a stateless service with backward-compatible changes.
- Capacity cost matters and rollback speed is acceptable.
Use Blue/green when
- Rollback must be immediate.
- You can afford double capacity for the window.
Use Canary when
- The change is risky and the failure would be visible.
- You have metrics good enough to gate on.
Verdict
Rolling for most changes, canary for risky ones, blue/green when instant rollback is worth double capacity. None of them help with a database migration that is not backward compatible.