A few years ago, if there was a discussion on “Should we run databases on Kubernetes?”, there were more people saying no than yes. One of the common answers was, “No. Kubernetes is for stateless workloads. Keep your databases outside.”
Thankfully, today the discussion is no longer about whether we should run databases on Kubernetes, but how we can run them better on Kubernetes.
In this post, we will look at some of the common arguments brought up against running databases on Kubernetes.
By far the most common concern
Even though Kubernetes was initially used mainly for stateless workloads, many additions have been made since its initial version to accommodate stateful workloads. Features like StatefulSet and PersistentVolumes were introduced, and storage usage has been streamlined through the Container Storage Interface (CSI). Furthermore, the platform itself has evolved to support system-level capabilities like Swap space to better manage memory-intensive databases.
Today, a large number of users are successfully running stateful workloads on K8s. According to the latest CNCF Annual Survey Report, stateful containers have become a standard practice, with 79% of Innovators now running stateful applications in production.
Is my data safe on Kubernetes even when pods, nodes, or the entire Kubernetes cluster go down?
This sounds terrifying at first, but cloud-native architecture is built with failure in mind. Pods die, nodes crash, and entire clusters can fail. The golden rule of running databases on Kubernetes is that your data must never depend on the lifecycle of the compute layer.
This is where the absolute decoupling of compute and storage becomes critical. The underlying storage infrastructure exists entirely independent of the Pod, Node, and even the Kubernetes cluster itself. As long as your storage backend is architected correctly, your data is preserved regardless of what happens to the compute environment.
For a database, this tiered isolation changes everything:
For replicated databases, a Kubernetes Operator can automate this resilience, detecting failures, promoting replicas, and reconciling your state across nodes, or even helping orchestrate disaster recovery across entirely different clusters.
What if a Pod or a node running a database goes down? Will the database experience downtime?
While failover concepts remain similar to traditional environments, Kubernetes transforms this into an automated, declarative process via Operators. Kubernetes automatically schedules a replacement Pod and reattaches it to the existing, intact storage volume. If the database is properly configured with a redundant, highly available configuration (recommended configuration), the remaining healthy Pods will continue to serve traffic. When utilizing Kubernetes solutions, you are delivering a data service powered by specific database technology, where high availability is maintained through a cluster of N Pods. The critical shift in mindset here is to focus on the service’s resilience rather than the survival of individual Pods; our goal is to optimize the overall service, not the individual Pod, a distinction that is often misunderstood.
While custom scripts might work well today, proprietary automation always comes with heavy long-term maintenance overhead. To scale effectively, automation should be split into two distinct layers: infrastructure and database management.
Because Kubernetes is widely adopted and continuously updated by the global community, it handles the infrastructure layer (compute, networking, and storage) out of the box. By adopting a good Operator, complex database-specific logic is offloaded. Ultimately, using Operators prevents you from reinventing the wheel and lets the teams focus on application value rather than maintaining custom infrastructure code.
Manually managing StatefulSets, PersistentVolumeClaims (PVCs), and various other Kubernetes objects to run a database on Kubernetes can be tedious.
This is where database operators emerge as game-changers.
An operator is a Kubernetes-native controller that watches custom resources and continuously works to move the actual system toward the desired state. As a user, you describe something like: “I want a database cluster with three instances, backups enabled, this storage, these resources, this version, monitoring enabled, and this replication setup.” The operator then handles everything under the hood, including managing Kubernetes objects and implementing the operational logic.
Instead of playing the role of a mechanic who has to assemble all the parts and make everything run, you simply get into a car built by expert mechanics and drive it. The operator abstracts away the complexity so you can focus on the outcome rather than the implementation details.
A very valid concern, especially for database engineers accustomed to carefully tuned virtual machines or bare-metal servers. Running databases inside Pods does introduce an additional abstraction layer. There may be a very small category of specialized, legacy “pet” databases that require highly specific bare-metal tuning and extreme isolation.
That said, the vast majority of configurations are achievable on Kubernetes. There are a few exceptions; for example, certain low-level storage tuning options may be limited by CSI driver abstractions. However, these are edge cases that rarely affect modern production deployments and do not impact the vast majority of database workloads.
For almost all modern production use cases, Kubernetes is more than capable of running databases reliably and efficiently.
Managed databases are a great fit for many use cases, as they remove significant complexity and operational overhead.
However, they do come with a few caveats:
In short, many of the concerns raised are no longer relevant today or do not apply to the majority of use cases.
It’s safe to say that databases run and run well on Kubernetes if configured well. In many cases, the shift is cultural rather than technical.
Running databases on Kubernetes offers the advantage of preventing vendor lock-in. Even though database migration tools exist, cloud migrations remain difficult in practice. This is especially true with major cloud vendors, where your data layer is often tightly integrated with a complex web-native ecosystem of services.
Operators excel at automating complex Day-2 operations like failovers, backups, and rolling updates. Running both your application and data layers under a single Kubernetes cluster provides a unified control plane for automation. This setup seamlessly aligns with GitOps workflows and becomes incredibly efficient when managing a large fleet of databases at scale.
We have seen users derive incredible value by running databases on Kubernetes with operators. Some use it to manage standard database instances, while others have built their own fully fledged, internal DBaaS (Database-as-a-Service) platforms, and the list is long. Selecting the right Operator makes all the difference on this journey. Opting for free and open-source operators like the Percona Operators not only provides enterprise-grade databases but also saves your teams significant time and money.
Resources
RELATED POSTS
