StatefulSet is a building block, not a data platform
A StatefulSet maintains a stable identity for each Pod and can associate individual replicas with persistent storage — Kubernetes documentation describes it as suitable for workloads requiring stable network identity, persistent storage, or ordered lifecycle behavior. That makes it an important building block. It is not a complete data platform.
Which stateful workloads commonly run on Kubernetes
When a stateful service should remain outside Kubernetes
The correct comparison is not Kubernetes versus old technology — compare a Kubernetes operator against a managed service, dedicated VMs, and existing enterprise platforms.
Operators: automate carefully
An Operator extends Kubernetes with application-specific controllers and custom resources — it can automate cluster creation, failover, backup, restore, scaling and upgrades. It can also become a critical dependency.
Review the maintainer, release frequency, supported Kubernetes and database versions, backup and restore methods, failure handling, and disaster-recovery documentation. A mature database running through an immature Operator may create more risk than running it on a well-managed VM.
Test what happens when the Operator Pod is unavailable, the Operator is upgraded, the CRD changes, or an administrator edits the underlying StatefulSet directly — the application should not become unrecoverable merely because its Operator installation was lost.
Persistent storage design
StorageClasses should represent real service levels, documented per class: CSI driver, replication, failure domain, performance expectation, snapshot capability and backup method. Do not let applications select storage classes from names alone.
Application consistency and snapshots
Kubernetes VolumeSnapshots provide a standardized interface for point-in-time copies through supported CSI drivers. A snapshot can support fast rollback and pre-upgrade protection — it does not automatically provide offsite protection, application consistency, or ransomware protection.
Some applications recover through journals; others require a flush, checkpoint, filesystem freeze, or database-native backup with transaction-log protection. The application owner must define the required consistency model — a PVC object without data is not a backup, and a volume snapshot without Kubernetes resources is not a complete application recovery set.
High availability, quorum and PodDisruptionBudget
A stateful application has at least two availability layers: process availability and data availability. Replacing a failed database Pod does not help if its volume is unavailable, the database lost quorum, or replicas contain stale data.
A three-member cluster may tolerate one member failure — it may still fail when two members share one node or zone, network policy blocks replication, or maintenance removes another member. Document voting rules, failure tolerance and split-brain prevention.
Backup architecture and recovery order
Protect every required layer: Kubernetes resources, operator CRDs, persistent-volume data, database-native backup, transaction logs, object storage, encryption keys, container images and recovery documentation. Use database-native protection when transaction consistency, point-in-time recovery, or log replay is required.
Test progressively: one file, one volume, one database, the Operator, custom resources, a complete namespace, and finally a restore into another cluster — validating business transactions and measuring RPO/RTO at each level. A running StatefulSet does not prove usable data.
A practical recovery order: recovery credentials → replacement cluster → CNI/CSI → snapshot controller → StorageClasses → CRDs → Operator → backup platform → database/persistent data → custom resources → dependent applications → Services/ingress → monitoring. Test the exact product — Operator behaviour may require a different order.
Scaling and upgrades
Stateful scaling is not the same as adding stateless web replicas — scale-out may require membership changes, data rebalancing and shard movement; scale-in may require data evacuation and quorum validation. Do not allow automatic scaling until the application's data movement and failure behavior are understood.
Separate upgrade changes where practical — a combined Kubernetes, Operator, database and storage upgrade creates a difficult rollback problem. Confirm old and new versions can coexist, the replication protocol is compatible, and a backup exists before any rolling update.
Common mistakes
It supplies identity and lifecycle behavior — not replication, backup, or consistency.
The class may not meet latency, failure-domain, snapshot or recovery requirements. Document its real behaviour.
Replica count without failure-domain separation provides weak availability. Spread replicas deliberately.
Maintenance may become blocked because no replacement Pod can schedule. Maintain headroom.
The snapshot may remain on the source storage system. Create an independent copy.
The Operator, custom resources, Secrets and service configuration may be missing. Protect the full application.
Adding or removing replicas may trigger expensive rebalancing or data loss. Test manually first.
Validate quorum, replication, data consistency and business transactions.
Stateful workload readiness checklist
0 / 24Frequently asked questions
It is an application that must preserve data, identity, membership or other state across Pod replacement and rescheduling.
It provides stable Pod identity, ordered lifecycle behavior, and stable persistent-volume relationships.
No. Data replication belongs to the application, database, storage system or Operator.
No. A single-instance application may use a Deployment with a PVC when stable identity and ordered lifecycle behavior are unnecessary.
Not automatically. Compare Kubernetes operation with managed services, virtual machines and dedicated database platforms.
It is an application-specific controller that uses custom resources and Kubernetes control loops to manage an application.
No. It can automate procedures, but teams still need to understand consistency, replication, backup, failure and recovery.
They can be part of a backup strategy, but they may remain on the source storage system and may not be application-consistent.
It limits concurrent voluntary disruption to selected Pods. It does not prevent involuntary failure or create spare capacity.
Some can, but scaling may require membership changes, rebalancing and storage provisioning. Test the application's specific behavior.
Protect Kubernetes resources, persistent data, application-native backups, transaction logs, encryption keys, Operators and external dependencies.
It must survive Pod and node failure, maintain consistent data, support controlled upgrades, restore into the required recovery environment, and pass business validation.
Run the data platform, not only the Pods
Kubernetes can provide a strong operating platform for stateful business applications — declarative management, consistent automation, storage integration and repeatable operations. Its risks appear when teams confuse process replacement with data recovery.
Choose the storage deliberately, evaluate the Operator, understand quorum and failure domains, protect Kubernetes resources and application data separately, and restore the full application into a replacement cluster before trusting it in production. Run the workload on Kubernetes when the organization can operate the entire data lifecycle there more reliably — keep it elsewhere when Kubernetes adds another control plane without improving availability, recovery or ownership.