Blue-green and canary solve the same problem, shipping a new version without a maintenance window, and charge different prices for it. Blue-green pays with a duplicate environment and buys an instant rollback; canary pays with the observability it demands and buys a smaller blast radius. This article works through the questions that decide between them.
Quick Overview
What you’ll learn:
- Why traffic volume alone can rule canary out before any tooling discussion
- What version-aware metrics are, and why canary is blind without them
- Which database migration discipline makes a rollback real rather than documented
- Where the choice of strategy stops mattering, and what to fix instead
Who this article is for:
- DevOps engineers maintaining deployment pipelines
- Team leads deciding how releases reach production
- Service owners accountable for availability after a deploy
Reading time: 7 minutes
What Each Approach Actually Does
The deployment strategies guide on cloud.google.com describes blue-green as keeping identical environments where only one serves production traffic: the new version lands on the idle environment, gets verified, and traffic then switches to it wholesale. Canary instead runs the new version alongside the old, giving it a small share of live traffic that grows in stages while indicators hold.
The real difference is where the decision sits. Blue-green has a single decision, taken before traffic arrives: switch or do not switch. Canary has as many decisions as it has traffic stages, each resting on a measurement taken in production. Blue-green therefore demands a trustworthy staging environment, canary demands trustworthy metrics, and those demands are not interchangeable.
A rolling update deserves naming here because it is frequently mistaken for canary: it replaces instances in sequence without splitting traffic by version. It is cheap and built into orchestrators, but it offers no point at which a version is assessed — it replaces everything, just more slowly.
How Much Traffic Does the Service Have
This question comes first because it can settle the matter outright. The canarying chapter in sre.google makes the usually-skipped point: evaluating a canary means comparing the population served by the new version with the population served by the old, and that comparison only holds when both are statistically similar and the observation window is long enough for a fault to surface.
A low-traffic service cannot satisfy that. Its first canary stage either runs long enough to stall the release or carries enough traffic that calling it a canary is generous. The constraint is arithmetic rather than tooling, so no deployment controller removes it — and for such services blue-green is the better answer.
Can Your Metrics Tell Versions Apart
The second question is discovered late in most teams. If the error rate is aggregated across the service, a new version producing faults inside its traffic share dissolves into noise and the alerting threshold never fires. Labelling metrics by version is a precondition of canary, not a refinement of it.
Traffic share then grows in stages whose thresholds come from your own traffic measurement rather than from somebody else’s example: the first stage must be small enough that a fault reaches few users and large enough that the observation window yields a meaningful request count. Both halves of that sentence are constraints, and services tend to fail the second one.
What Does Your Database Migration Permit
The third question is where rollbacks turn out to be theoretical. A schema change that the previous code cannot read makes the return path unavailable, whichever deployment strategy shipped it — the traffic switch succeeds and the application fails.
The discipline that fixes it belongs to change management rather than deployment: a backward-compatible schema change ships as its own release before the code that uses it, and the removal of the now-unused schema elements ships as a later release once the new version has proven stable. Session state deserves the same scrutiny: sessions pinned to in-memory state on an instance survive neither a blue-green switch nor a canary ramp.
Where the Choice Stops Mattering
The DORA metrics described on dora.dev now fall into two groups, with names worth quoting precisely. Delivery throughput is measured by change lead time (from commit in version control to deployment), deployment frequency, and failed deployment recovery time. Instability is measured by change fail rate and deployment rework rate — the share of deployments that are unplanned and follow a production incident. A deployment strategy moves the instability measures and the recovery time, and barely touches change lead time or deployment frequency, which follow from change size and pipeline throughput. A team adopting canary in order to deploy more often is repairing the wrong component.
The continuous delivery capability page on dora.dev names the practices that raise throughput: trunk-based development, automated testing and deployment automation. The traffic-splitting mechanism at the end of the line is not among them — that conclusion is ours, not the page’s. Strategy is the last metre of a long pipeline.
Nor does the choice settle whether deployment is separated from release. Feature flags let code reach production switched off and be enabled by a separate decision; that is a different safeguard from splitting traffic by version, and neither substitutes for the other. It also does not settle pipeline security: the CI/CD risk list on owasp.org catalogues classes that are indifferent to release mechanics — over-permissioned pipeline jobs, weak access control on the version control system, dependencies from untrusted sources. Every strategy deploys exactly what the pipeline handed it.
Read Also
- CI/CD: automated software deployment, a practical guide — the pipeline a release comes out of
- Building a CI/CD pipeline from scratch — standing up a pipeline that supports these strategies
- Observability: logs, metrics and traces in practice — the logs, metrics and traces that supply the signal for promoting or rolling back a canary
Build Your Skills
This topic is covered by Argo CD — continuous deployment for Kubernetes and DevOps fundamentals — culture, practices and tools. The first works on the GitOps tooling these strategies are driven from in a cluster; the second establishes the practices a deployment strategy rests on. Talk to us about matching the scope to your pipeline.
Frequently Asked Questions (FAQ)
Which approach suits a low-traffic service?
Blue-green, because canary needs a request count sufficient to evaluate a stage within a reasonable time. At low volume the first canary stage either takes too long or is too large to deserve the name. Blue-green has no such constraint: the decision rests on verification against the idle environment rather than on a production measurement.
Does canary need duplicate environments like blue-green?
No, both versions run in the same environment and share traffic. The cost moves to measurement: metrics must carry a version label and alerting rules must act on that label. That work lands in the observability layer rather than in infrastructure, which is why canary is often cheaper to host and more expensive to adopt.
How do we roll back a release that changed the database schema?
Through change discipline rather than deployment strategy. The schema change ships as its own backward-compatible release, the code using it ships next, and the removal of unused schema elements ships after that. A code rollback then works, because the previous version still reads a schema you deliberately left readable by both.
Do feature flags replace blue-green and canary?
No, they answer a different question. Splitting traffic by version protects against a defect in new code as a whole; a feature flag lets a capability be exposed independently of the code deployment. Teams using both have cover at either level, while teams using flags alone still ship all their code at once.