The Chicken-and-Egg Problem of the Cloud Controller Manager in Kubernetes
Kubernetes 1.31 has completed the largest migration in Kubernetes history by removing the in-tree …

Operating databases in Kubernetes was long considered risky: Stateful workloads, persistent data, and container orchestration seemed incompatible. Today, the situation is different. Specialized operators, optimized storage solutions, and proven practices have made relational and document-based databases stable building blocks for cloud-native architectures.
While hyperscalers like AWS, Google, or Azure simplify operations with cloud-hosted DBaaS offerings (e.g., RDS, CloudSQL, CosmosDB), questions remain: Vendor lock-in, sovereignty, compliance. Companies seeking full control and flexibility therefore opt for self-hosted databases in Kubernetes.
In this article, we compare three popular databases and their operators for Kubernetes:
We analyze their features in terms of scaling, clustering, backups, monitoring, and day-2 operations. Additionally, we provide insights into how ayedo has successfully operated stateful database workloads in Kubernetes for many years, particularly in conjunction with Longhorn, a powerful storage solution with data locality and built-in replication.
The advantages are clear:
At the same time, databases in Kubernetes require a deeper understanding of storage, networking, and day-2 operations. This is where strong implementations stand out from weaker ones.
CloudNativePG is a CNCF project fully focused on PostgreSQL in Kubernetes.
The MariaDB Operator brings the popular MySQL fork DB into Kubernetes.
The MongoDB Operator is the official solution for document-based database workloads.
| Feature | PostgreSQL (CloudNativePG) | MariaDB (Operator) | MongoDB (Operator) |
|---|---|---|---|
| Clustering | Automatic, robust | Galera, complex with latency | ReplicaSets + Sharding |
| Scaling | Read Replicas | Read Replicas, Multi-Master | Sharding, Replica Sets |
| Backups | pgBackRest, PITR | XtraBackup, mysqldump | Ops Manager |
| Monitoring | Prometheus + Grafana | PMM + Prometheus | Prometheus, Grafana |
| Day-2 Operations | Rolling Updates, PITR | Scale-Out, Failover | Upgrades, Sharding, Migrations |
| Community | CNCF, open | MySQL community, Percona | MongoDB Inc., commercial |
All three operators offer native integration with Prometheus and Grafana. Differences lie in the depth of dashboards and exporters.
For logs, a central solution like Grafana Loki or Elasticsearch is recommended. Operators usually provide standard log integration, which can be collected by agents like Promtail or Vector.
“Day-2” refers to all operations after the initial deployment. These include:
Here, the differences are noticeable:
At ayedo, we have successfully operated stateful database workloads in Kubernetes for many years. The combination with Longhorn has proven particularly effective:
This setup allows us to operate relational and document-based databases stably, performantly, and with high availability in Kubernetes – without relying on cloud DB services.
Self-hosted databases in Kubernetes are no longer experiments but proven reality. The choice of the appropriate operator depends heavily on the workloads and organizational requirements:
With storage solutions like Longhorn, these databases can be operated performantly and resiliently – offering a real alternative to cloud-hosted DBs without sacrificing sovereignty and flexibility.
Kubernetes 1.31 has completed the largest migration in Kubernetes history by removing the in-tree …
In the industry, a fundamental architectural question arises: Should AI make decisions directly at …
Nothing is more frustrating for a customer than a “Click & Collect” experience that …