Skip to main content

Hosting Databases within Kubernetes

While researching and writing this Kubernetes series, I probably went through hundreds of articles, forum posts, and Reddit comments about a single core question:

Should I host a database within my Kubernetes cluster, or should I use a managed database service instead?

It's a question that continues to pop up frequently, and honestly, as someone who's still relatively new to Kubernetes, it's not surprising why. The concern is valid and widely shared among both beginners and experts, not just in the Kubernetes community but also in modern DevOps and infrastructure contexts.

The Historical Context: Stateless vs. Stateful​

For a long time, the best practices around Kubernetes have revolved around the concept of "stateless" applications. The principles behind Kubernetes were designed to scale and recover from failures effortlessly. Because of its inherent design for self-healing and declarative state, Kubernetes excels at running stateless applications, where any pod or container can die, be recreated, and get back to running almost immediately, with no impact on the application's availability, given that these don’t carry persistent data within themselves.

Here's a typical example:

  • Imagine a web server or an API service. If one of the replicas of a stateless service goes down or gets killed by the scheduler, Kubernetes just spins up another one somewhere else, connects it to the load balancer, and resumes traffic, all without anyone noticing. Simple!

But when it comes to stateful workloads like databases, it's a different story. This is where Kubernetes' stateless-first orientation starts to clash with the persistence and durability requirements of databases. The whole point of a database is to store data in a reliable and consistent way that survives pod failures, node restarts, or even an entire cluster shutting down.

The dilemma boils down to this simple point: How do we reconcile stateless infrastructure with stateful services like databases?

The Challenge of Stateful Applications​

When you introduce stateful services, such as databases, into a Kubernetes cluster, you encounter some key challenges:

Persistent Storage:

  • Stateless apps don’t care about storage or data. In contrast, a database relies heavily on persistent storage to store and retrieve data without losing it. Fortunately, Kubernetes has matured in this area with components such as Persistent Volumes (PVs) and Persistent Volume Claims (PVCs), which allow pods to retain data even if they are recreated. But managing these can still be tricky, especially in scenarios of node failure or during cluster migrations.

Data Consistency and Durability:

  • Databases are critical to maintaining data consistency and often need to replicate data across nodes to ensure durability and high availability. Any deployment failure or pod misplacement could lead to potential data corruption or downtime. Using stateful sets for databases helps address this, but it requires careful orchestration of failover, recovery, and scaling.

Disaster Recovery and Backups:

  • When a database is managed independently of Kubernetes (e.g., through a cloud provider), backup and restore processes are simplified. In Kubernetes, organizations need to carefully define backup strategies to avoid data loss during disruptions.

Performance and Resource Contention:

  • Applications running in a Kubernetes cluster often compete for shared resources (CPU, memory, I/O bandwidth). Large, resource-hungry databases may face performance bottlenecks, especially in clusters designed primarily for serving stateless microservices. Dedicated hosting of databases reduces the risk of congestion and performance hits.

Scaling:

  • Scaling stateless applications in Kubernetes is trivial, up and down scaling is as simple as updating the replica count of a deployment. Scaling stateful applications, particularly relational databases, is much more complex. Horizontal scaling for databases often requires complex sharding or replication, each with its own intricacies.

When Does Database Hosting in Kubernetes Make Sense?​

Kubernetes has developed significantly since its stateless-first beginnings, and modern workloads have shown that stateful applications, including databases, can be successfully hosted in Kubernetes, but it comes with trade-offs that you need to carefully assess based on your use case.

Here are situations where hosting a database in Kubernetes might make sense:

Portability Across Multiple Environments​

If you want consistency across your development, staging, and production environments, Kubernetes offers the advantage of running databases exactly the same way anywhere—whether that's on-premises, in the cloud, or even across hybrid-cloud setups. With the right configurations, you can move your entire application, including its database, as a single, unified package.

Cost-Efficiency with Self-Hosting​

Managed cloud databases provide convenience and reliability but come at a cost (often significant when scaling out). Running a database inside your Kubernetes cluster, especially in on-premise environments, can be much more cost-efficient. It allows for better utilization of server capacity, as you’ll be using the same resources to host both the application and database.

Advanced Kubernetes Features​

Kubernetes has introduced a variety of features that make running databases smoother:

  • StatefulSets: These provide ordered deployment, scaling, and self-healing of persistent pods used with your database.
  • Persistent Volumes & Claims: Enable your pods to store data independently of their lifecycle, ensuring persistent data even if pods die.
  • Operators: Kubernetes operators (e.g., for MySQL, PostgreSQL, MongoDB) have become more capable in simplifying the management of complex stateful apps such as databases, handling replication, failover, backups, and more automatically.

When Should You Use Managed Databases?​

Though running stateful services and databases in Kubernetes is possible, for many teams, the complexities may outweigh the benefits. In particular, managed databases (e.g., AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL/MySQL, etc.) have remained a more popular choice in many production environments.

Here are some reasons why you might opt for a managed database instead of self-hosting in Kubernetes:

Focused Reliability​

Managed database services are specifically optimized for uptime, with guarantees around availability, fault tolerance, and backups. Cloud providers take care of infrastructure management, including failover and hardware reliability, which is ideal for workloads requiring strong service level agreements (SLAs).

Simpler Setup and Maintenance:​

With managed databases, you don’t need to worry about keeping your database software up to date, scaling it as your system grows, ensuring data is backed up, or managing disaster recovery strategies. This level of automation around operational concerns can drastically reduce maintenance overhead.

Scalability Without Complexity:​

Cloud-managed databases allow you to scale up (vertically) or replicate databases easier, without having to configure sharding or complex replication setups typically required for self-hosted databases.

Conclusion​

The decision on whether to host your database on Kubernetes or use a managed database highly depends on your specific needs. From cost-efficiency to required complexity, there are legitimate use cases for both approaches.

In general:

If you don't want to manage the complexities of running and maintaining a database (backups, scaling, failover, etc.), a managed database service might be your best bet.

However, if you require higher control, flexibility, or have specific portability needs (e.g., managing everything in Kubernetes, running on-premises, or multi-cloud without cloud-vendor lock-in), hosting a database within Kubernetes might make more sense.