Running databases on Kubernetes is like relying on a fragile flash drive for critical data—prone to risks, downtime, and data loss due to storage management complexities. Tagged with kubernetes, database, devops, storage.

Aishwary Gupta

Venture Capital

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

Running databases on Kubernetes can be risky due to the potential for storage issues such as dangling Persistent Volumes (PV) and Persistent Volume Claims (PVC). The concept is likened to using a flash drive for critical data storage, with similar risks of data corruption and resource waste. The reliance on the CSI controller in Kubernetes can lead to data inaccessibility and manual recovery, making it less suitable for highly stateful, storage-intensive applications like databases.

Why Running Databases on Kubernetes is Like Storing Critical Data on a Fragile Flash Drive

Comparison: Flash Drives vs. PVC/PV in Kubernetes

Conclusion: Why Databases and Kubernetes Aren’t Always a Great Match

I’d disagree. You can use local storage on a node and dedicate a node to just the database. Then you anti affinities to make sure no more than 1 pod for the database is scheduled on the node.
For example, I use CNPG to run a postgres instance and two replicas all on different nodes with dedicated local storage. Kubernetes is my replacement for managing patroni and allows me to automate fail over with minimal or no extra setup.

you can bet your ass aws is running rds in some sort of k8 environment.
of course there are challanges but there’s nothing better than k8 for now.

The article provides no solution - oof.