Databases in Kubernetes – Alternatives to Cloud-Hosted DB

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:
- PostgreSQL with CloudNativePG
- MariaDB with MariaDB Operator
- MongoDB with MongoDB Kubernetes Operator
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.
Why Databases in Kubernetes?
The advantages are clear:
- Automation: Operators handle routine tasks (provisioning, updates, failover).
- Flexibility: Usable on-premises or in multi-cloud environments.
- Cost Efficiency: No dependency on cloud provider pricing.
- Sovereignty: Full control over data, storage, and security.
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.
PostgreSQL with CloudNativePG
CloudNativePG is a CNCF project fully focused on PostgreSQL in Kubernetes.
Features
- Clustering: Automatic replication and failover with a Patroni-like approach.
- Scaling: Support for read replicas for horizontal scaling.
- Backups: Integrated with pgBackRest.
- Monitoring: Exporter for Prometheus, dashboards in Grafana.
- Day-2 Operations: Rolling updates, automatic failover, point-in-time recovery.
Advantages
- CNCF community-driven, openly developed.
- Very close to PostgreSQL standards.
- Broad integration with cloud storage and on-prem storage.
Disadvantages
- Focused only on PostgreSQL, no multi-DB functionality.
- Complexity with very large clusters (>100 nodes).
MariaDB with MariaDB Operator
The MariaDB Operator brings the popular MySQL fork DB into Kubernetes.
Features
- Clustering: Automated Galera cluster integration.
- Scaling: Horizontally scalable via read replicas.
- Backups: Supports mysqldump, Percona XtraBackup.
- Monitoring: Integration with Percona Monitoring and Management, Prometheus exporter.
- Day-2 Operations: Automated upgrades, scale-out, failover.
Advantages
- Mature technology with a long-standing community.
- Strong MySQL compatibility.
- Galera offers multi-master scenarios.
Disadvantages
- Galera clusters can become complex with network latencies.
- Backup/restore less integrated than with CloudNativePG.
MongoDB with MongoDB Kubernetes Operator
The MongoDB Operator is the official solution for document-based database workloads.
Features
- Clustering: Sharding and replica sets are automated.
- Scaling: Automatic replication, horizontal scaling through shards.
- Backups: Integration with Ops Manager.
- Monitoring: Exporter for Prometheus, dashboards in Grafana.
- Day-2 Operations: Automated upgrades, schema migrations.
Advantages
- Seamless MongoDB integration, directly from the vendor.
- Sharding out-of-the-box.
- Suitable for large, dynamic data volumes.
Disadvantages
- Dependency on MongoDB Inc., some features are commercial only.
- Higher resource requirements compared to relational DBs.
Comparison of Operators
| 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 |
Metrics, Logs, and Alerts
All three operators offer native integration with Prometheus and Grafana. Differences lie in the depth of dashboards and exporters.
- PostgreSQL: Mature exporters (postgres_exporter), detailed dashboards.
- MariaDB: MySQL-compatible exporters, integration with PMM.
- MongoDB: Exporter from the MongoDB Monitoring Project.
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 Operations
“Day-2” refers to all operations after the initial deployment. These include:
- Backups & Restores: Integration into central backup strategies.
- Upgrades: Rolling updates, automatic versioning.
- Failover: Self-healing and rescheduling.
- Observability: Dashboards, alerts, logs.
- Security: TLS, secrets management, user management.
Here, the differences are noticeable:
- CloudNativePG excels with seamless PITR and robust upgrade mechanisms.
- MariaDB Operator impresses in multi-master setups but requires network discipline.
- MongoDB Operator is very powerful but comes with stronger vendor lock-in.
ayedo Practice: Databases + Longhorn
At ayedo, we have successfully operated stateful database workloads in Kubernetes for many years. The combination with Longhorn has proven particularly effective:
- Data Locality: Data stays close to the NVMe disks of the nodes.
- Replication: Built-in replication protects against node failures.
- Performance: Optimized for high-speed storage.
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.
Conclusion
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:
- PostgreSQL (CloudNativePG) for relational standards, high reliability, and community support.
- MariaDB Operator for MySQL compatibility and multi-master scenarios.
- MongoDB Operator for highly scalable, document-based workloads.
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.