Common objections to running databases on Kubernetes are examined and rebutted. The post covers concerns about stateful workloads, data safety during pod/node failures, performance overhead, and operational complexity. It argues that Kubernetes has matured significantly with StatefulSets, PersistentVolumes, and CSI, and that Kubernetes Operators now automate complex Day-2 database operations like failovers, backups, and rolling updates. The piece concludes that most historical objections are no longer valid, and that running databases on Kubernetes with a good operator offers benefits like vendor lock-in avoidance, unified control planes, and GitOps alignment.
Table of contents
1. Kubernetes was designed for stateless workloads2. Is my data safe on Kubernetes?3. Won’t My Database Experience Downtime When Pods or Nodes Go Down?4. I have already built a lot of custom automation in our in-house environment. Why should I switch to Operators?5. Managing Pods, PVCs and configuration is painful6. I can configure bare-metal or VM nodes exactly how I want for database workloads, but Kubernetes makes this level of customization impossible.7. Managed databases are way better than running on kubernetesConclusion201.8K Impressions13 Comments