Can rolling deployment cause issues with database schemas?

Yes — this is the main challenge. During a rolling deployment, both the old and new application versions run simultaneously and both hit the same database. Your migration must be backward-compatible: add columns, do not rename or drop them until the old version is gone.

How do you roll back a rolling deployment?

In Kubernetes, kubectl rollout undo deployment/ triggers a new rolling update that replaces the new version pods with the old version image. It is fast but not instant — it takes as long as the forward rollout did.

What is a "maxSurge" and "maxUnavailable" in Kubernetes rolling updates?

maxSurge controls how many extra pods above the desired count can exist during the update; maxUnavailable controls how many pods can be down simultaneously. Setting maxUnavailable: 0 guarantees zero downtime (but requires extra capacity for the surge pods).

Deployment strategy comparison

Rolling vs Recreate Deployment

Two fundamental Kubernetes deployment strategies. Rolling is the default for a reason — but Recreate is sometimes the right call when running two versions simultaneously would break things.

TL;DR

Rolling replaces old instances gradually — zero downtime, but both versions run simultaneously during the transition. Requires backward-compatible schema changes.
Recreate kills all old instances before starting the new ones — causes brief downtime, but guarantees only one version runs at any time. Safe for breaking schema changes.
Default to Rolling. Use Recreate only when running two versions simultaneously is technically impossible or causes data corruption.

Side-by-side comparison

Aspect	Rolling	Recreate
Downtime	Zero (with maxUnavailable: 0)	Brief downtime between old teardown and new startup
Rollback	Rolling rollback (takes time)	Rolling rollback (or re-Recreate)
Resource usage	Temporarily higher (surge pods)	Lower — no overlap period
Complexity	Moderate — tune maxSurge, maxUnavailable	Simple — just stop all, then start all
Schema compatibility	Must be backward-compatible	Breaking changes are safe (no overlap)
Versions running simultaneously	Yes — briefly	No — strict one-version-at-a-time
Speed	Controlled by batch size	Fast to initiate; limited by startup time
Best for	Production, user-facing services	Dev/staging, workers, breaking migrations

Config side-by-side

Kubernetes Deployment strategy field:

Rolling (Kubernetes default)

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 1 extra pod allowed
      maxUnavailable: 0  # never take pods down
                         # before replacement is ready

Recreate

spec:
  strategy:
    type: Recreate
  # No additional parameters.
  # Kubernetes terminates ALL old pods,
  # then starts ALL new pods.
  # Expect a gap in availability.

When to use Rolling

User-facing production services. Any downtime is unacceptable — rolling is the default Kubernetes strategy for good reason.
Frequent deployments. If you deploy dozens of times per day, brief maintenance windows would accumulate into significant downtime.
Additive schema changes. Adding a new nullable column or a new index is backward-compatible; the old app ignores it and the new app uses it.
Graceful shutdown supported. Your app handles SIGTERM, drains in-flight requests, and shuts down cleanly — so replacing pods one by one works without dropped connections.

When to use Recreate

Breaking schema migrations. Renaming a column, changing a data type, or dropping a table — the old and new versions cannot coexist against the same schema.
Exclusive resource access. Services that hold a singleton lock (single writer to a file, exclusive leader) break when two instances run simultaneously.
Non-critical internal workers. Background jobs, data importers, and dev/staging environments where a few seconds of downtime is acceptable.
Memory-constrained clusters. No budget for surge pods — you need the old instances gone before new ones consume memory.

English phrases engineers use

Rolling deployment conversations

"We set maxUnavailable to zero — no pod goes down before its replacement is ready."
"The rollout is in progress — three of ten pods are on the new version."
"We need a backward-compatible migration or rolling won't work."
"I'll pause the rollout while we investigate the latency spike."
"kubectl rollout undo will revert to the previous revision."

Recreate conversations

"We're doing a Recreate because the migration renames a column."
"There'll be a maintenance window of about 30 seconds."
"All pods are terminating — new ones start once they're gone."
"This is a breaking change — we can't run both versions at once."
"Schedule the deploy for off-peak hours to minimise impact."

Quick decision tree

Zero downtime required → Rolling
Breaking schema migration (rename, drop column) → Recreate
Singleton / exclusive resource lock → Recreate
Dev or staging environment → Recreate (simpler)
High-frequency deploys (CI/CD) → Rolling
Cluster is memory-constrained, no surge capacity → Recreate
User-facing API, SLA in place → Rolling

Common Mistakes and Trade-offs

A very common mistake teams make when evaluating Rolling vs. Recreate deployments is equating 'smaller risk' with 'Rolling' simply because it involves a gradual rollout. This leads to the assumption that any change, however small, automatically benefits from the inherent safety of continuous delivery. In reality, a poorly designed, rapidly deployed change – even if only affecting a small percentage of users – can still cause significant disruption and rollback complexity if not thoroughly tested at each stage. The illusion of control with Rolling is often predicated on a lack of robust monitoring and immediate feedback loops; without them, you're just delaying the inevitable cascade of problems rather than mitigating them. Careful consideration must be given to the potential impact of any change, regardless of its size or deployment frequency.

At scale, Recreate deployments expose a significant architectural trade-off: data consistency. Rolling deployments inherently introduce periods where different versions of your application are serving users concurrently, potentially leading to inconsistent data states across databases and caches. While techniques like feature flags and canary releases can mitigate this risk with Rolling, the underlying problem remains – you're still running multiple versions simultaneously. Recreate, while requiring a full database migration, provides a clean slate for each deployment, guaranteeing immediate consistency at the cost of downtime and potentially higher operational overhead. The decision here hinges on your application's tolerance for data divergence and the complexity of managing concurrent deployments.

The misconception that 'Rolling' is always better for complex applications – especially those with significant database schema changes – is a persistent one. Rolling deployments, by their nature, attempt to minimize disruption by incrementally changing parts of the system. However, substantial schema migrations require coordinated updates across all impacted services, and attempting this in parallel with other changes introduces immense complexity and risk. The rollback process becomes exponentially more difficult as new versions are introduced. Recreate deployments provide a reliable mechanism for applying these large-scale changes atomically – either everything succeeds or everything reverts cleanly – avoiding the fragmented state that Rolling can easily create.

Successfully transitioning between Rolling and Recreate deployments, or even combining them strategically, requires a layered approach. Teams often attempt a direct switch without proper planning; this frequently results in significant friction during the migration process. A more nuanced strategy involves using Rolling for smaller, less impactful changes while reserving Recreate deployments for critical schema migrations or substantial application updates. Furthermore, implementing automated rollback procedures that intelligently analyze deployment logs and automatically trigger a Recreate if a Rolling deployment fails to stabilize within a predefined timeframe is crucial. This combined approach allows you to leverage the strengths of both methodologies while actively mitigating their respective weaknesses.

Frequently asked questions

What is rolling deployment?

Rolling deployment replaces instances of the old version one at a time (or in small batches) with the new version. At any point during the rollout, both the old and the new version are running simultaneously, so traffic keeps flowing with zero downtime.

What is recreate deployment?

Recreate deployment shuts down every instance of the old version first, then starts the new version. This produces a brief window of complete downtime — all old pods are terminated before any new ones accept traffic.

When is recreate deployment acceptable?

Recreate is fine for non-critical internal services, batch workers, development or staging environments, or any service where a brief maintenance window is acceptable and backward compatibility between versions is impossible.

Show more questions (3)