Databases in Kubernetes – Alternatives to Cloud-Hosted DB
Fabian Peter 4 Minuten Lesezeit

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.
container - kubernetes - databases - postgresql - mariadb - mongodb - operators

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.

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.

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.