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

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)