Closer to Serverless for Databases on Kubernetes

For cloud-native applications, containers are the default approach to deployment. According to the CNCF/Linux Foundation Annual Survey in 2022, 44% of organizations used containers for most or all of their applications, while 35% used them for some or a few of their apps. Since then, containers have been used for other elements of the application stack, covering security, networking and databases. Kubernetes has emerged as the cornerstone for orchestrating containerized applications. However, running these stateful elements like databases on Kubernetes has led to new and unique challenges and opportunities, particularly in the domain of autoscaling.

For many of us, we might assume that Kubernetes would automatically handle scaling; after all, orchestrating workloads in response to demand is what it was built for. However, Kubernetes was not designed with databases in mind, and autoscaling the database and storage resources needed by modern applications is a problem that still has to be solved.

At the same time, autoscaling is not just a luxury but a necessity in modern cloud-native environments. It ensures that applications meet performance requirements, especially during peak times, while keeping costs under control by right-sizing the workloads. For developers, it promises a worry-free environment where resource management becomes an afterthought, enabling them to focus on innovation and development.

The Indispensable Role of Kubernetes Operators

The advent of Kubernetes Operators revolutionized the way we run databases on Kubernetes. These operators extend Kubernetes’ capabilities, automating routine tasks and solving basic problems for users. They encapsulate the domain knowledge of running complex services, making the deployment, management, and scaling of databases more efficient and less error-prone. Operators are instrumental in achieving the vision of “closer to serverless” for databases, where complexity is abstracted away and operations are streamlined. At the same time, Operators are still in development – as more functionality like autoscaling is needed, these Operators will be where that work takes place.

Kubernetes Operators also allow developers to get similar user experience and automation capabilities to public cloud database services, but at a fraction of the cost compared to locking into one of these services. This helps avoid the issues of growing cloud bills and cost management that many companies face today.

Why is Storage Scaling so Hard?

To make auto-scaling work in practice, one of the most formidable challenges is storage scaling. Kubernetes, while robust in handling stateless applications, shows its limitations when it comes to scaling stateful sets, which is a crucial aspect of managing database storage. The current model requires numerous steps to scale storage resources for data workloads, highlighting a significant gap in Kubernetes’ capability to manage database storage dynamically. Additionally, the lack of a unified approach to scaling across different Kubernetes operators exacerbates the problem, leading to fragmented and often inefficient scaling strategies.

To solve this problem, we will have to work closely with the whole community to find a better way to automate storage scaling while also keeping this consistent across multiple databases and Kubernetes operators that companies may use. While Percona supports the likes of MySQL, PostgreSQL and MongoDB with database distributions and operators, the reality is that developers may have other databases in place that they also want to apply autoscaling to. The user experience we are looking for is to remove manual work for resizing volumes but also constantly monitor various thresholds to make an informed decision whether volume should be scaled or not.

Making the Most of Container Resource Scaling

A promising development in addressing compute scaling challenges is Kubernetes’ introduction of in-place container resource scaling. This feature enables the adjustment of a container’s resources without the need for Pod restarts. This marks a significant step forward towards minimizing downtime and enhancing the efficiency of resource management across Kubernetes clusters.

At the same time, this capability is particularly crucial for databases, where high availability and minimal disruption are paramount. Restarts should not lead to downtime but might result in performance degradation, leading to potential application performance issues and poor customer experience overall. By letting Kubernetes make changes to resources without requiring pod restarts, database clusters can be expanded or reduced to meet demand levels without that performance or availability hit.

As databases scale, ensuring that their configuration aligns with the available resources becomes critical. Autotuning mechanisms play a vital role in this aspect, dynamically adjusting database parameters to optimize performance and resource utilization. This not only ensures that databases operate at their optimal capacity but also reduces the manual overhead involved in tuning configurations. This will improve automated management of databases over time, helping developers move closer to the same truly serverless experience that they can achieve around other application components..

Improving Databases on Kubernetes Over Time

The journey towards a serverless experience for databases on Kubernetes is fraught with challenges, yet it is also filled with opportunities for innovation. By leveraging Kubernetes Operators, addressing storage scaling issues, adopting in-place resource scaling, and implementing autotuning, we can significantly simplify database management.

These advancements enhance operational efficiency. However, they also pave the way for a future where developers can unleash their creativity without being bogged down by the intricacies of resource management. As we continue to evolve and refine these technologies, The headaches that currently surround cloud infrastructure management will disappear, leaving developers to focus on solving business problems and developing what comes next.


To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.

Sergey Pronin

Sergey Pronin is a product leader at Percona focusing on delivering robust open source database and cloud-native solutions. Prior to Percona, Sergey led product management and engineering teams in other organizations with a primary focus on products in infrastructure and platforms space.

Sergey Pronin has 1 posts and counting. See all posts by Sergey Pronin