Kubernetes

Stateful Applications on Kubernetes: Databases, Queues, and Beyond

Kubernetes was designed for stateless workloads, but StatefulSets, PersistentVolumes, and operators have made it viable for stateful applications too. Running databases and queues on Kubernetes gives you unified tooling, but it requires careful attention to storage, backup, and failure handling.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

StatefulSets vs Deployments

StatefulSets provide guarantees that Deployments do not: stable network identities (pod-0, pod-1, pod-2), ordered startup and shutdown, and stable persistent storage. Each pod in a StatefulSet gets a PersistentVolumeClaim that follows it across rescheduling. This is essential for databases that need consistent hostnames for replication (e.g., PostgreSQL streaming replication where replicas connect to the primary by hostname). Use a Headless Service (`clusterIP: None`) with StatefulSets to give each pod a predictable DNS name like `pod-0.my-service.my-namespace.svc.cluster.local`.

PersistentVolumes and Storage Classes

PersistentVolumeClaims (PVCs) request storage from a StorageClass, which provisions the underlying volume (EBS on AWS, Persistent Disk on GCP, Azure Disk). Use `volumeBindingMode: WaitForFirstConsumer` so volumes are provisioned in the same availability zone as the pod. Set `reclaimPolicy: Retain` to prevent accidental data loss when a PVC is deleted. For databases, use SSDs (`gp3` on AWS, `pd-ssd` on GCP) and provision sufficient IOPS. Monitor disk usage with Prometheus alerts to catch volumes approaching capacity before they cause crashes.

Database Operators for Automated Management

Operators automate the lifecycle of complex stateful applications. The CloudNativePG operator manages PostgreSQL clusters with automated failover, backup to S3, point-in-time recovery, and rolling upgrades. The Strimzi operator does the same for Apache Kafka. The Redis operator from Spotahome manages Redis Sentinel and Cluster topologies. These operators encode operational expertise in code: they handle leader election, replica promotion, backup scheduling, and certificate rotation, dramatically reducing the DBA burden on small teams.

When to Keep Databases Outside Kubernetes

Running databases on Kubernetes is viable, but managed database services (RDS, Cloud SQL, Azure Database) offload backup, patching, failover, and performance tuning. If your team lacks Kubernetes expertise for storage operations, or if your database has strict IOPS and latency requirements, a managed service may be the safer choice. A hybrid approach works well: run your application on Kubernetes and use managed databases externally, connecting via private endpoints or VPC peering. This gives you Kubernetes benefits for stateless workloads without the risk of self-managed databases.

Why Anubiz Engineering

100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included

Ready to get started?

Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.