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

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.