For years, the idea of running databases on Kubernetes was met with a reaction that was swift, blunt, and often justified: hell no. Kubernetes was built to orchestrate stateless applications (i.e., workloads that could be spun up, scaled out, and terminated without consequence). Databases, on the other hand, are the direct opposite. They are stateful, durability-sensitive, performance-critical systems where even small disruptions can have serious consequences.
Database experts warned that adding an abstraction layer to such stateful applications would compromise data integrity, performance, security, and stability. This was a hot topic in my early days at Percona in 2017/2018. And for a time, they were somewhat justified. Over the years, though, those perceptions have changed. And as more organizations embrace cloud-native database deployments, the more confident others become in the practice.
Recent surveys have found that over 70% of organizations that employ Kubernetes use it to run databases. And that isn’t reserved solely for development, either. Another industry survey recently revealed that nearly half of organizations now run 50% or more of their data workloads on Kubernetes in production, with leaders surpassing 75%. Meanwhile, over 60% attribute more than 10% of their company’s revenue to these deployments.
What was once unthinkable is now increasingly common. Not because teams have become reckless, but because Kubernetes itself (and the ecosystem around it) has matured enough to make running databases a pragmatic choice in the right circumstances.
See also: Scaling Your Application Infrastructure with Kubernetes & Microservices
Why “Hell No” Once Made Sense
To understand why attitudes are shifting, it helps to remember why the original objections existed in the first place. Kubernetes was designed around the idea of ephemeral workloads. Containers were meant to be disposable. Pods could be rescheduled at any time. Failures were expected and handled through replacement, not preservation. That model works beautifully for stateless services. But databases don’t work that way.
Databases require persistent storage, strict consistency guarantees, careful failover coordination, and predictable I/O performance. They also demand operational rigor: backups must be reliable, upgrades must be controlled, and recovery processes must be tested.
In Kubernetes’ early days, many of the building blocks for these requirements were immature. Storage support was inconsistent. StatefulSets were basic. Operational tooling for backup and restore was limited. Observability for stateful workloads lagged behind what teams were used to in traditional environments. So when experienced DBAs pushed back, they weren’t wrong. Running databases on Kubernetes was, in fact, risky for many organizations at that stage.
See also: 3 Ways Kubernetes Adoption Fosters Resiliency
As Kubernetes Matures, Database Containerization Takes Hold
The reason this conversation looks different today is not that databases suddenly became less demanding. It’s because the Kubernetes ecosystem has become significantly more capable. And now that the Kubernetes ecosystem has matured, operators can encode best practices for deployment, scaling, backups, and recovery, making it possible to run many database workloads safely and efficiently.
One of the biggest changes that enabled this shift has been the rise of database operators— Kubernetes-native controllers that encode operational best practices into software. Instead of relying on manual processes and tribal knowledge, operators can automate the lifecycle of a database: provisioning, scaling, backups, replication, failover, and even upgrades. This is a fundamental change. Operational expertise that once lived only in the heads of a few specialists can now be made repeatable, testable, and consistent across environments.
At the same time, Kubernetes infrastructure has matured. The Container Storage Interface (CSI) has improved persistent storage portability. Networking performance has become more predictable. Managed Kubernetes offerings have reduced the burden of cluster operations. Tooling for observability and security has advanced significantly.
In short, Kubernetes has evolved from an orchestrator for stateless microservices into a platform capable of supporting more complex workloads — including, increasingly, databases.
The Real Driver: Convenience, Not Recklessness
One of the most misunderstood aspects of this shift is the motivation behind it. Organizations are not running databases on Kubernetes because they want to gamble with data safety. They’re doing it because they want operational simplicity, automation, and consistency.
Developer expectations have changed, especially as the rise of cloud providers like AWS and Azure has raised expectations around convenience. Teams want infrastructure that is self-service, API-driven, and integrated into modern workflows. And while undeniably convenient, hyperscaler-managed database services come with significant trade-offs: vendor lock-in, opaque pricing, limited portability, and reduced control over architecture and upgrades. Kubernetes offers an alternative path, one with cloud-like convenience, but on open source terms.
Ultimately, that is what’s driving adoption. It is pragmatism, borne out of a desire for speed and convenience, without sacrificing self-determination.
Kubernetes is Where Flexibility and Freedom Combine
The bigger story here goes beyond just databases. It’s about where infrastructure is heading on the whole. Organizations want the flexibility and transparency of open source. They also want the usability and speed of hyperscaler platforms.
Kubernetes is increasingly becoming the layer that connects those worlds: offering a consistent operational model across environments while avoiding dependence on proprietary platforms. In that context, running databases on Kubernetes is part of a broader shift: enterprises building cloud-native experiences without surrendering control.
The original “hell no” came from a valid place. Data is anything but disposable, and therefore, databases demand caution. But, technology evolves: tooling matures, practices improve, and trust builds upon that new reality. Today, the question is no longer whether databases can run on Kubernetes, but what databases can’t. And the number of databases that fall into that bucket is steadily declining.
For many organizations, using Kubernetes for databases has gone from an experimental risk to a calculated, pragmatic choice. And that shift serves as a clear reflection of how modern infrastructure is built and operated today.
