I'm new to Kubernetes and using it for a side project to learn. I'm trying to decide whether my cluster should host only stateless services or also run systems such as PostgreSQL, Kafka, and Redis with StatefulSets. Both approaches are technically possible, but I'm more interested in what teams commonly do in production. Do most organizations use operators and persistent storage to run stateful workloads in Kubernetes, or do they keep those systems on managed services, dedicated VMs, or separate infrastructure? I'd also like to understand the tradeoffs around backups, failover, upgrades, storage, cost, and operational effort.
4 Answers
Running PostgreSQL, Redis, or Kafka in Kubernetes can work very well when the team has the operational experience and a real reason to do it. Some organizations use dedicated VMs, local disks with replicated followers, or distributed storage such as Ceph, combined with backups and log shipping to object storage. Kubernetes can provide consistent deployment and security workflows, but it does not remove the need to understand the database, storage, networking, and recovery process.
StatefulSets by themselves only solve the basic pod identity and storage attachment problem. For production PostgreSQL or Kafka, you generally want a mature operator such as CloudNativePG or Strimzi, along with tested backups, failover procedures, monitoring, and disaster recovery. The difficult part is usually the storage layer: volume replication, snapshots, zonal placement, node loss, and confirming that a replacement pod can actually access its data. Operators can make this workable, but they also add another component that must be upgraded and maintained alongside Kubernetes.
For PostgreSQL with high availability, an operator can handle leader routing, replicas, backups, and failover much more reliably than a hand-written StatefulSet. You still need to test recovery yourself and define acceptable RTO and RPO targets.
A single-node lab is useful for learning the mechanics, but it cannot demonstrate real node failures or cross-zone behavior. Those scenarios need multiple workers and storage that supports the failure modes you want to test.
A useful way to compare the options is to define your recovery objectives first. Decide how much downtime is acceptable (RTO) and how much committed data could be lost (RPO), then test failover, backup restoration, upgrades, and node or storage failures against those targets. For a learning project, self-hosting with an operator is a good exercise. For a small production service, keeping the primary database managed is often the safer default unless you have a clear cost, compliance, latency, or feature-based reason to do otherwise.
The common choice for small teams is to run application workloads in Kubernetes while using managed databases and messaging services. Providers usually handle much of the backup, failover, upgrade, and disaster-recovery work, which can be worth more than the infrastructure savings from self-hosting. Running stateful services in the cluster makes sense when cost, compliance, latency, portability, or provider limitations are important enough to justify the extra operational responsibility.
For a small team, managed services are often the better tradeoff because database incidents and upgrades can happen at the worst possible time. The decision should be based on the team’s ability to operate the system, not just whether Kubernetes supports it.
Managed services are not automatically simpler for every workload. They can impose limits on extensions, authentication, backup restores, observability, placement, and infrastructure-as-code. Self-hosting can be preferable when those constraints matter and the team is prepared to operate the system.