Cloud‑Datenbanken versprechen einfache Skalierung, hohe Verfügbarkeit und ein transparentes "Pay‑as‑you‑go"-Preismodell.

In der Praxis erleben viele Unternehmen jedoch das Gegenteil: Datenbankkosten gehören oft zu den größten und am schwersten planbaren Posten der Cloud‑Rechnung.

Dieser Vortrag geht der Frage nach, warum Cloud‑Datenbanken so häufig teurer sind als erwartet – selbst bei moderaten Workloads. Ausgehend von typischen Migrations‑ und Einführungs­szenarien zeigt der Vortrag, dass hohe Kosten nur selten durch einzelne "Fehlkonfigurationen“ entstehen. Viel häufiger sind sie das Ergebnis architektonischer Entscheidungen, die unter Cloud‑Randbedingungen anders wirken als im On‑Prem‑Rechenzentrum.

Anhand konkreter Beispiele werden zentrale Kostentreiber analysiert: stets laufende Instanzen, überdimensionierte Ressourcengrößen, I/O‑ und Speicher‑Tiers, Backup‑ und Replikationskosten sowie insbesondere Netzwerk‑ und Egress‑Gebühren, die in verteilten Architekturen schnell dominieren. Ein besonderer Fokus liegt auf einem verbreiteten Denkfehler: der Annahme, dass Managed‑Datenbank‑Services operative Komplexität eliminieren.

Der Vortrag zeigt, warum sich Komplexität stattdessen in Kosten, Abhängigkeiten und eingeschränkte Gestaltungsspielräume verlagert – etwa durch starre Skalierungsmodelle, eingeschränkte Einflussmöglichkeiten auf Speicher‑Layouts oder die enge Kopplung an proprietäre Cloud‑Dienste.

Darüber hinaus wird beleuchtet, warum klassische Migrationsansätze wie Lift‑and‑Shift in der Cloud oft zu dauerhaft überhöhten Datenbankkosten führen und wie datenbank‑ und workload‑spezifische Zugriffsmuster die Kosten exponentiell verstärken können. Auch neue Anforderungen durch Analytics‑ und KI‑Workloads werden eingeordnet, die Datenbewegung und Speicherbedarf weiter erhöhen.

Der Vortrag schließt mit einem Blick auf Kostenbewusstsein als Architekturdisziplin: Welche Prinzipien helfen, Datenbankkosten langfristig kontrollierbar zu halten? Warum sind Einfachheit, Entkopplung und bewusste Technologieauswahl oft wirksamer als nachträgliche FinOps‑Optimierung?

Ziel ist es, Cloud‑Datenbankkosten vor der ersten Rechnung zu verstehen – und nicht erst, wenn sie nicht mehr zu erklären sind.