Kubernetes Deployment vs StatefulSet: When to Use Which

The most common Kubernetes mistake I see in production is using a Deployment where a StatefulSet is required — or, less commonly, using a StatefulSet where a Deployment would work fine and introducing unnecessary operational complexity.

These two workload types are not variants of the same thing. They encode fundamentally different assumptions about your application. A Deployment assumes your pods are disposable and interchangeable. A StatefulSet assumes they are not. Choosing wrong doesn't immediately break things — which is why it survives into production.

What a Deployment Assumes

A Deployment manages a ReplicaSet, which manages a set of identical, interchangeable pods. The key word is identical. A Deployment makes no guarantees about:

• Which pod handles which request — a load balancer distributes traffic to any healthy pod
• Pod naming — pods get random suffixes (api-7d4f9c8b6-xkpqr, api-7d4f9c8b6-mnwtz)
• Storage continuity — if a pod is rescheduled to a different node, it gets a fresh volume
• Startup or shutdown order — pods scale up and down in arbitrary order

Those are not limitations — they are the design. A Deployment is built for stateless workloads where any pod can handle any request, pods can be killed and replaced without data loss, and horizontal scaling means adding identical copies.

Web servers, REST APIs, background workers, gRPC services — anything that reads from an external database and doesn't hold state locally — these are Deployment workloads.

What a StatefulSet Guarantees

A StatefulSet provides three guarantees that a Deployment deliberately does not:

1. Stable, Persistent Network Identity

Each pod in a StatefulSet gets a predictable, stable hostname that survives pod rescheduling. Pod 0 is always pod-name-0, pod 1 is always pod-name-1. Combined with a headless Service (clusterIP: None), each pod gets a stable DNS entry:

pod-name-0.service-name.namespace.svc.cluster.local
pod-name-1.service-name.namespace.svc.cluster.local

This matters for databases and distributed systems that need to address specific peers. A Kafka broker needs to know which broker it is. An etcd member needs a stable address so other members can reach it. Elasticsearch nodes need to discover and form a cluster with specific peers. None of that works if pod names are random.

2. Stable, Persistent Storage

Each pod in a StatefulSet gets its own PersistentVolumeClaim created from a volumeClaimTemplate. When pod postgres-0 is rescheduled to a different node, it reconnects to the same PVC — its data follows it.

1volumeClaimTemplates:
2  - metadata:
3      name: data
4    spec:
5      accessModes: ["ReadWriteOnce"]
6      storageClassName: gp3
7      resources:
8        requests:
9          storage: 100Gi

With a Deployment, you can attach a PVC, but all replicas share the same volume (requiring ReadWriteMany access mode, which most block storage providers don't support) or each pod gets an independent volume with no guaranteed reconnection after rescheduling.

3. Ordered, Graceful Deployment and Scaling

StatefulSet pods are created, updated, and deleted in a defined order. Scale up: pod 0 starts first, pod 1 starts after pod 0 is Running and Ready, and so on. Scale down: pods terminate in reverse order — pod N first.

This matters for distributed systems with quorum requirements. A three-node etcd cluster requires a majority (two nodes) to elect a leader. If you scale down by removing nodes in arbitrary order, you can inadvertently lose quorum and split-brain the cluster. StatefulSet ordered deletion prevents this.

The Decision is Usually Obvious

Use a Deployment for:

• Web servers and API services
• Background workers consuming from queues
• Batch processors
• Stateless microservices of any kind
• Any service where requests to any replica produce the same result

Use a StatefulSet for:

• Databases (PostgreSQL, MySQL, MongoDB, Cassandra)
• Distributed caches that persist data (Redis with AOF/RDB, Memcached with persistence)
• Message brokers (Kafka, RabbitMQ, Pulsar)
• Distributed coordination systems (etcd, ZooKeeper)
• Search engines (Elasticsearch, OpenSearch)
• Any workload where individual pod identity matters to the application

The deciding question: does your application care which specific pod it is? If pod app-0 and pod app-5 are completely interchangeable with no coordination between them — use a Deployment. If pod kafka-0 needs to know it's broker 0 and maintain its own log segment — use a StatefulSet.

Where This Gets Complicated

Stateful applications behind a cache layer

Some teams run a stateful backend (say, PostgreSQL) behind a stateless connection pooler (PgBouncer). The pooler is a Deployment. PostgreSQL is a StatefulSet. That's the right split — but I've seen teams run PgBouncer as a StatefulSet because they assumed "anything database-adjacent must be StatefulSet." PgBouncer holds no data. It's a Deployment.

Read replicas

A PostgreSQL primary is a StatefulSet with a single replica (replicas: 1). Read replicas are also StatefulSets, but they sync from the primary using replication slots tied to their stable hostname. You cannot use a Deployment for read replicas because streaming replication depends on the replica advertising a stable network identity back to the primary.

Redis

Standalone Redis (single instance, no persistence) — Deployment works fine. Redis Sentinel — the sentinel pods need stable identities to track the primary, so StatefulSet. Redis Cluster — absolutely StatefulSet, each shard has a slot range assigned to its identity.

Kafka

Every Kafka broker is a StatefulSet. The broker ID is tied to the pod ordinal. Broker 0 owns specific partition replicas. If you used a Deployment and pod kafka-2 was replaced with a random name, the cluster would not recognise it as the broker that owns those partitions. The topic metadata would be inconsistent.

Common Mistakes

Using Deployment with a ReadWriteOnce PVC. You'll get Multi-Attach error immediately when Kubernetes tries to schedule a second pod to a different node. The volume is already mounted on node A. The fix is not to switch to ReadWriteMany — it's to ask why your workload needs multiple replicas of the same mounted volume, and whether a StatefulSet with per-pod PVCs is the right answer.

Using StatefulSet for a stateless service "just to be safe." The cost: rolling updates are slower (ordered), scaling is slower (ordered), and you've added PVC management overhead for volumes that hold nothing meaningful. StatefulSets are not "more reliable" than Deployments — they're a different contract.

Deleting a StatefulSet without deleting its PVCs. StatefulSet deletion does not cascade to PersistentVolumeClaims by default. Those volumes keep billing you and can conflict with a redeployed StatefulSet if the PVC names match. Always check kubectl get pvc -n <namespace> after removing a StatefulSet.

Skipping the headless Service. A StatefulSet without a headless Service defined in spec.serviceName is incomplete. The stable DNS entries (pod-0.service.namespace.svc) only exist if the headless Service exists. This is a silent failure — pods start fine, but peer discovery fails at runtime.

Update Strategies

Both workload types support rolling updates, but the mechanics differ.

A Deployment with RollingUpdate replaces pods in parallel up to maxSurge and maxUnavailable limits. Old and new pods can run simultaneously. Order doesn't matter.

A StatefulSet with RollingUpdate replaces pods in reverse order — highest ordinal first. pod-2 is replaced, becomes Ready, then pod-1, then pod-0. This ensures the primary or leader (usually pod-0 in most operator conventions) is updated last, after all replicas have been successfully updated.

For Kafka, databases with leader election, and other systems where pod-0 is often the primary: this ordering is deliberate and important. Don't fight it.

Quick Reference

Frequently Asked Questions

Can I convert a Deployment to a StatefulSet?

Not in-place — Kubernetes won't let you change the workload type of an existing resource. In practice, you delete the Deployment, create the StatefulSet with the same pod template, and migrate data if needed. For stateless services that you're adding storage to, plan for downtime or a blue-green cutover.

Can a StatefulSet have zero replicas?

Yes. replicas: 0 is valid and scales down all pods while keeping the StatefulSet spec and PVCs intact. This is useful for pausing a database during maintenance without losing the storage configuration.

Does StatefulSet guarantee exactly-once delivery?

No. StatefulSet guarantees ordered, at-most-one-at-a-time pod management by default (podManagementPolicy: OrderedReady). If you need parallel pod management with stable identities, use podManagementPolicy: Parallel. Exactly-once semantics are an application-level concern, not a Kubernetes primitive.

When should I use a DaemonSet instead?

A DaemonSet runs exactly one pod per node (or per matching node). Use it for node-level agents: log shippers (Fluentd, Filebeat), monitoring agents (node-exporter, Datadog Agent), CNI plugins, and security scanners. It's not a substitute for either Deployment or StatefulSet — it solves a different problem entirely.

My StatefulSet pods are stuck in Pending — what's wrong?

Most commonly: the PersistentVolumeClaim can't be fulfilled. Check kubectl describe pvc <pvc-name> — you'll usually see either no StorageClass that matches the request, insufficient capacity on the storage backend, or a zone mismatch (the PVC was created in us-east-1a but the pod is scheduled to a node in us-east-1b with a ReadWriteOnce volume).

For a deeper look at running stateful workloads specifically, see Databases in Kubernetes: Smart Move or Unnecessary Risk?.

Running stateful workloads in Kubernetes and hitting edge cases? Talk to us at Coding Protocols — we help platform teams design workload architectures that hold up under operational load.