Datenbanken in Kubernetes – Alternativen zur Cloud-Hosted DB

Der Betrieb von Datenbanken in Kubernetes galt lange Zeit als riskant: Stateful Workloads, persistente Daten und Container-Orchestrierung schienen nicht zusammenzupassen. Heute ist die Lage eine andere. Durch spezialisierte Operatoren, optimierte Storage-Lösungen und bewährte Praktiken sind relationale und dokumentenbasierte Datenbanken inzwischen stabile Bausteine für Cloud-native Architekturen.

Während Hyperscaler wie AWS, Google oder Azure mit Cloud-hosted DBaaS-Angeboten (z. B. RDS, CloudSQL, CosmosDB) den Betrieb stark vereinfachen, bleiben Fragen offen: Vendor Lock-in, Souveränität, Compliance. Unternehmen, die volle Kontrolle und Flexibilität wünschen, setzen daher auf Self-Hosted Datenbanken in Kubernetes.

In diesem Artikel vergleichen wir drei populäre Datenbanken und deren Operatoren für Kubernetes:

• PostgreSQL mit CloudNativePG
• MariaDB mit MariaDB Operator
• MongoDB mit MongoDB Kubernetes Operator

Wir analysieren deren Features im Hinblick auf Skalierung, Cluster-Bildung, Backups, Monitoring und Day-2-Operations. Außerdem geben wir einen Einblick, wie wir bei ayedo seit vielen Jahren erfolgreich Stateful Database Workloads in Kubernetes betreiben – insbesondere im Zusammenspiel mit Longhorn , einer leistungsfähigen Storage-Lösung mit data locality und eingebauter Replikation.

Warum Datenbanken in Kubernetes?

Die Vorteile liegen auf der Hand:

• Automatisierung: Operatoren übernehmen Routineaufgaben (Provisionierung, Updates, Failover).
• Flexibilität: Einsetzbar on-premises oder in Multi-Cloud-Umgebungen.
• Kosteneffizienz: Keine Abhängigkeit von Cloud-Provider-Pricing.
• Souveränität: Volle Kontrolle über Daten, Speicher und Security.

Gleichzeitig gilt: Datenbanken in Kubernetes erfordern ein tieferes Verständnis von Storage, Netzwerk und Day-2-Betrieb. Hier trennen sich gute von schwachen Implementierungen.

PostgreSQL mit CloudNativePG

CloudNativePG ist ein CNCF-Projekt, das sich vollständig auf PostgreSQL in Kubernetes spezialisiert hat.

Features

• Cluster-Bildung: Automatische Replikation und Failover mit Patroni-ähnlichem Ansatz.
• Skalierung: Unterstützung von Read Replicas für horizontale Skalierung.
• Backups: Integriert mit pgBackRest .
• Monitoring: Exporter für Prometheus , Dashboards in Grafana .
• Day-2-Operations: Rolling Updates, automatische Failover, Point-in-Time Recovery.

Vorteile

• CNCF-Community-getrieben, offen entwickelt.
• Sehr nahe an PostgreSQL-Standards.
• Breite Integration mit Cloud-Storage und On-Prem Storage.

Nachteile

• Fokus nur auf PostgreSQL, keine Multi-DB-Funktionalität.
• Komplexität bei sehr großen Clustern (>100 Nodes).

MariaDB mit MariaDB Operator

Der MariaDB Operator bringt die beliebte MySQL-Fork-DB in Kubernetes.

Features

• Cluster-Bildung: Automatisierte Galera-Cluster-Integration.
• Skalierung: Horizontal skalierbar über Read Replicas.
• Backups: Unterstützt mysqldump, Percona XtraBackup.
• Monitoring: Integration mit Percona Monitoring and Management , Prometheus Exporter.
• Day-2-Operations: Automatisierte Upgrades, Scale-Out, Failover.

Vorteile

• Reife Technologie mit langjähriger Community.
• Starke MySQL-Kompatibilität.
• Galera bietet Multi-Master-Szenarien.

Nachteile

• Galera-Cluster können bei Netzwerk-Latenzen komplex werden.
• Backup/Restore weniger integriert als bei CloudNativePG.

MongoDB mit MongoDB Kubernetes Operator

Der MongoDB Operator ist die offizielle Lösung für dokumentenbasierte Datenbank-Workloads.

Features

• Cluster-Bildung: Sharding und Replica Sets werden automatisiert.
• Skalierung: Automatische Replikation, horizontale Skalierung durch Shards.
• Backups: Integration mit Ops Manager .
• Monitoring: Exporter für Prometheus, Dashboards in Grafana.
• Day-2-Operations: Automatisierte Upgrades, Schema-Migrationen.

Vorteile

• Nahtlose MongoDB-Integration, direkt vom Vendor.
• Sharding out-of-the-box.
• Geeignet für große, dynamische Datenmengen.

Nachteile

• Abhängigkeit von MongoDB Inc., einige Features nur kommerziell.
• Höhere Ressourcenanforderungen im Vergleich zu relationalen DBs.

Vergleich der Operatoren

Metrics, Logs und Alerts

Alle drei Operatoren bieten native Integration mit Prometheus und Grafana . Unterschiede liegen in der Tiefe der Dashboards und Exporter.

• PostgreSQL: Reife Exporter (postgres_exporter ), detaillierte Dashboards.
• MariaDB: MySQL-kompatible Exporter, Integration mit PMM .
• MongoDB: Exporter aus dem MongoDB Monitoring-Projekt .

Für Logs empfiehlt sich eine zentrale Lösung wie Grafana Loki oder Elasticsearch . Operatoren liefern meist Standard-Log-Integration, die durch Agents wie Promtail oder Vector gesammelt werden kann.

Day-2-Operations

„Day-2" bezeichnet alle Operationen nach der Erstbereitstellung. Dazu zählen:

• Backups & Restores: Einbindung in zentrale Backup-Strategien.
• Upgrades: Rolling Updates, automatische Versionierung.
• Failover: Self-Healing und Rescheduling.
• Observability: Dashboards, Alerts, Logs.
• Security: TLS, Secrets-Management, Benutzerverwaltung.

Hier sind die Unterschiede spürbar:

• CloudNativePG punktet durch nahtloses PITR und robuste Upgrade-Mechanismen.
• MariaDB Operator überzeugt bei Multi-Master-Setups, erfordert aber Netzwerkdisziplin.
• MongoDB Operator ist sehr mächtig, jedoch mit stärkerer Vendor-Bindung verbunden.

ayedo Praxis: Datenbanken + Longhorn

Wir bei ayedo betreiben seit vielen Jahren erfolgreich Stateful Database Workloads in Kubernetes. Besonders bewährt hat sich dabei das Zusammenspiel mit Longhorn :

• Data Locality: Daten bleiben nah an den NVMe-Disks der Nodes.
• Replikation: Eingebaute Replikation schützt vor Node-Ausfällen.
• Performance: Optimiert für Hochgeschwindigkeits-Storage.

Dieses Setup erlaubt es uns, relationale und dokumentenbasierte Datenbanken stabil, performant und hochverfügbar in Kubernetes zu betreiben – ohne auf Cloud-DB-Services angewiesen zu sein.

Fazit

Self-Hosted Datenbanken in Kubernetes sind keine Experimente mehr, sondern praxiserprobte Realität. Die Wahl des passenden Operators hängt stark von den Workloads und organisatorischen Anforderungen ab:

• PostgreSQL (CloudNativePG) für relationale Standards, hohe Zuverlässigkeit und Community-Support.
• MariaDB Operator für MySQL-Kompatibilität und Multi-Master-Szenarien.
• MongoDB Operator für hochskalierbare, dokumentenbasierte Workloads.

Mit Storage-Lösungen wie Longhorn lassen sich diese Datenbanken performant und resilient betreiben – und bieten damit eine echte Alternative zu Cloud-hosted DBs, ohne Souveränität und Flexibilität aufzugeben.