When "which replica am I" and "my own disk" matter, use a StatefulSet.

Deployment Pods are interchangeable and randomly named. StatefulSet Pods have stable names, stable DNS and their own PVC that follows them.

Deployment

random names, any order, shared or no storage

x7k2pm3n9qr8t4z

StatefulSet postgres

stable ordinals, created in order, each with its own PVC

pg-0→ pvc data-pg-0

pg-1→ pvc data-pg-1

pg-2→ pvc data-pg-2

Ordered lifecycle

Created 0, 1, 2 (each Ready first). Scaled down from the highest ordinal. Updated in reverse order, so pg-0 is touched last.

Headless Service gives DNS per Pod

pg-0.postgres.shop.svc.cluster.local always reaches pg-0, even after it moves nodes.

Manual canary with `partition`

partition: 2 updates only pg-2. Verify, then lower the number to roll out further.

volumeClaimTemplates:
- metadata: {name: data}
  spec: {accessModes: [ReadWriteOnce], resources: {requests: {storage: 20Gi}}}

StatefulSet: stable identity and storage

Deployments assume every Pod is interchangeable. Databases, brokers and clustered systems are not: replica zero may be the primary, each replica has its own data, and peers address each other by name. A StatefulSet provides what those need: a stable name (pg-0, pg-1, pg-2), a stable network identity through a headless Service, and per-replica storage created from volumeClaimTemplates that stays bound to that ordinal across restarts and rescheduling.

The lifecycle is ordered. Pods are created one at a time and each must be Running and Ready before the next starts. Scaling down removes the highest ordinal first. Rolling updates proceed in reverse ordinal order, so pg-0 is updated last and you have the most chance to halt the rollout before the most important replica is touched. Many stateful systems rely on membership changes happening in a predictable order.

partition is a powerful safety control. Setting partition to 2 on a three-replica set updates only ordinals 2 and above, leaving pg-0 and pg-1 on the old template. You can validate the new version on one replica before lowering the partition to continue, a manual canary for stateful workloads where a bad rollout is expensive to undo.

Gotchas: deleting a StatefulSet does not delete its PVCs by default (a safety feature that also leaves orphaned volumes and costs); and StatefulSets give you identity, not replication. You still need the database's own replication or an operator that automates failover, which Deck 7 covers.

When "which replica am I" and "my own disk" matter, use a StatefulSet.

Ordered lifecycle

Headless Service gives DNS per Pod

Manual canary with partition

Manual canary with `partition`