TL;DR: For stateless services, canary and blue-green are mostly a question of taste and tooling. For stateful services, the deployment strategy is secondary — the schema and data migration strategy is what actually determines safety. Get the expand-contract migration pattern right and either deployment strategy works; get it wrong and both will produce an incident, just on different timelines.
Why this question gets asked wrong
Most comparisons frame canary versus blue-green as a traffic-routing decision: shift 5% of requests gradually and watch metrics (canary), or flip 100% of traffic atomically between two full environments (blue-green). That framing is complete for stateless, idempotent services. It is dangerously incomplete for anything backed by a database, a cache with write-through semantics, or a message queue with ordering guarantees — which is most production services that matter.
The real question for a stateful service is: can the old version and the new version of my application safely read and write the same data store at the same time? If the answer is yes, both canary and blue-green are viable, and the choice comes down to blast-radius tolerance and release cadence. If the answer is no, neither strategy is safe until you fix the underlying migration approach — a canary deployment with a non-backward-compatible schema change is not a safer release, it's a slower-motion version of the same incident.
The core pattern: expand-contract migrations
The expand-contract pattern (also called parallel change) is what makes progressive delivery safe for stateful services, independent of which traffic strategy you pick:
- Expand. Modify the schema to support both the old and new application behavior simultaneously — add the new column as nullable, add the new table without dropping the old one, add the new message field without removing the deprecated one. Deploy this migration alone, with no application behavior change.
- Migrate/dual-write. Deploy the new application version, which writes to both old and new schema shapes (or backfills historically). At this point both old and new application versions are running against a schema that satisfies either.
- Contract. Once 100% of traffic runs the new version and you've confirmed no rollback is needed, remove the old columns, tables, or fields in a separate deployment.
This is intentionally slower than a single atomic schema change — that's the point. It converts one risky moment (deploy code and schema together) into three low-risk moments (schema change alone, code change against a permissive schema, schema cleanup alone), each independently reversible.
Canary: when it fits stateful services
Canary makes sense when:
- The change is application-logic-level and the schema is either unchanged or already expand-contract-safe.
- You have real-time metrics with low enough lag to make a rollback decision before damage compounds (telemetry lag is a genuine failure mode — deciding based on 5-minute-old dashboards while a bad canary writes bad data for 5 minutes is worse than no canary at all).
- Traffic is naturally partition-able (by user, by tenant, by region) so a canary cohort doesn't randomly interleave old/new writes to the same row in ways that create write conflicts.
Canary is the wrong tool when the failure mode is irreversible on write — a canary that corrupts 5% of records doesn't limit damage to 5% of impact if those records are shared state other requests read (e.g., an inventory count, a ledger balance, a session token). In these cases, the "small blast radius" promise of canary is an illusion; the blast radius is determined by data topology, not traffic percentage.
Blue-green: when it fits stateful services
Blue-green's core promise — instant, atomic rollback by flipping a router — only holds for the data layer if the new version's writes are still readable by the old version, i.e., you're still inside an expand-contract window. If the new (green) environment has already contracted the schema (dropped the old columns), flipping back to blue means blue is now reading a schema it doesn't understand. Blue-green rollback speed is a statement about the network/routing layer; it says nothing about data layer reversibility unless you've deliberately preserved it.
Blue-green fits well when:
- Releases are infrequent enough that maintaining two full parallel environments (including their data replication) is operationally affordable.
- The organization needs a near-zero-downtime cutover and can tolerate the cost of running duplicate infrastructure during the cutover window.
- Session state is externalized (Redis, a shared cache) rather than held in-process, so neither blue nor green environment owns state the other can't see.
A decision framework
| Signal | Favors Canary | Favors Blue-Green |
|---|---|---|
| Release frequency | Multiple times/day | Weekly or less |
| Schema change involved | None or already expand-contract-safe | Any — needs the atomic-cutover safety net during the expand-contract window |
| Failure detection latency | Fast metrics, low telemetry lag | Metrics are lagging or noisy; want a hard gate instead |
| Data partition-ability | High (per-tenant, per-region) | Low — shared global state |
| Infra cost tolerance | Lower (no duplicate full environment) | Higher (two full environments running in parallel) |
| Rollback semantics needed | Gradual traffic reduction | Instant, atomic |
In practice, many teams end up running both: blue-green at the infrastructure/environment level for the atomic cutover guarantee, with canary-style percentage rollout within the new (green) environment before it takes full traffic. This isn't indecision — it's using each tool for the layer it's actually good at.
Failure modes to design against
Schema and code deployed together. The single most common cause of stateful-deployment incidents. Whatever traffic strategy you use, decouple the schema migration deploy from the application code deploy into separate, independently revertable steps.
Session state trapped in-process. If in-flight requests hold session or connection state tied to a specific pod or instance, any traffic-shifting strategy will strand or drop that state mid-request. Externalize session state before attempting either canary or blue-green on a stateful service — this is a prerequisite, not an optional hardening step.
Feature-flag toggles that can't undo writes. A feature flag that disables new logic doesn't undo the writes that logic already made. If the plan is "we'll just toggle the flag off if something's wrong," verify that's actually true for every write path the new code touches — otherwise the real rollback plan is a data-repair script, and that should be written and tested before the deploy, not during the incident.
CDC and downstream consumers. If a change-data-capture pipeline (Debezium, Kafka Connect, or similar) is reading from the table you're migrating, expand-contract needs to account for consumers that haven't caught up to the new schema shape yet — a downstream consumer reading old-format events while your producer has already contracted the schema will silently drop or misparse fields.
Readiness probes that lie. Kubernetes readiness and liveness probes that check only "is the process up" rather than "can this pod actually serve traffic correctly against the current schema state" will route traffic to pods that are technically alive but functionally broken during a migration window.
Sources: How to Implement Blue-Green and Canary Deployments in Kubernetes, Blue-green deployment vs progressive delivery: Choosing a deployment strategy — Unleash, Achieving Progressive Delivery: Challenges And Best Practices — Octopus Deploy
Syslabs' engineering team designs zero-downtime deployment pipelines for stateful production systems as part of our cloud infrastructure work.