(g+) Rechenleistung nach Bedarf: Wie serverless sind Serverless-Datenbanken wirklich?

Was geschehen ist: Das Versprechen der bedarfsgerechten Datenbank

Das Konzept der Serverless-Datenbanken zielt darauf ab, die klassische, starre Infrastrukturplanung in der IT zu revolutionieren. In vielen Unternehmen existieren Datenbankanwendungen, die ein ungleichmäßiges Lastprofil aufweisen. Ein typisches Beispiel hierfür ist ein internes Buchungsportal, das morgens nur sporadisch genutzt wird, am Monatsende jedoch durch umfangreiche Datenimporte massiv belastet wird, um nachts wiederum nahezu vollständig ungenutzt zu bleiben. Bisher mussten IT-Teams solche Systeme für den maximalen Lastgipfel dimensionieren, was dazu führte, dass in den ruhigen Phasen teure Rechenkapazitäten ungenutzt blieben. Serverless-Datenbanken versprechen hier eine Lösung: Die Plattform stellt Rechenleistung exakt dann bereit, wenn sie benötigt wird, und reduziert diese in inaktiven Phasen automatisch. Im Idealfall kann die Kapazität sogar auf null sinken, wodurch die Notwendigkeit entfällt, eine Instanz permanent laufen zu lassen. Dies soll nicht nur die Kosten für Leerlaufzeiten minimieren, sondern auch den administrativen Aufwand für die Kapazitätsplanung und die allgemeine Infrastrukturverwaltung drastisch reduzieren. Die grundlegende Idee ist es, den Fokus der Entwickler von der Hardware-Dimensionierung hin zur eigentlichen Anwendungslogik zu verschieben.

Die Einzelheiten: Technische Herausforderungen und offene Fragen

In der Praxis ist das Modell jedoch mit komplexen Fragestellungen verbunden, die über das reine Marketingversprechen hinausgehen. Fabian Deitelhoff weist in seinem Beitrag vom 6. September 2026 darauf hin, dass die vermeintliche Einfachheit neue technische Hürden schafft. Ein zentraler Punkt ist die Latenz: Wie lange muss die erste Anfrage warten, wenn sich die Datenbank im Ruhezustand befindet und erst hochfahren muss? Zudem stellt sich die Frage nach der Skalierbarkeit der Architektur. Es muss geklärt werden, ob der Dienst lediglich CPU und Arbeitsspeicher skaliert oder ob er auch in der Lage ist, die Schreiblast intelligent auf verschiedene Knoten zu verteilen. Ein weiteres Szenario betrifft die Nebenläufigkeit: Was passiert, wenn beispielsweise 100 Funktionen gleichzeitig versuchen, Verbindungen zur Datenbank aufzubauen? Diese technischen Details entscheiden darüber, ob eine Serverless-Lösung für eine spezifische Anwendung performant genug ist. Zudem bleibt die Kostenfrage oft intransparent, sobald neben der reinen Rechenleistung auch Faktoren wie Speicherplatz, automatisierte Backups und die tatsächliche I/O-Last in die monatliche Abrechnung einfließen. Die bloße Abwesenheit eines laufenden Servers bedeutet nicht zwangsläufig, dass das System in der Gesamtkostenrechnung günstiger abschneidet.

Hintergrund: Warum Serverless als Lösung gilt

Die Entwicklung hin zu Serverless-Modellen ist eine direkte Antwort auf die Ineffizienzen traditioneller Cloud-Infrastrukturen. Lange Zeit war es Standard, Datenbanken auf dedizierten Servern oder fest zugewiesenen Instanzen in der Cloud zu betreiben. Diese mussten so konfiguriert sein, dass sie auch unter Lastspitzen nicht in die Knie gingen. Die Folge war eine massive Überdimensionierung, da man für den 'Worst Case' zahlte, während das System im Durchschnitt nur einen Bruchteil dieser Ressourcen verbrauchte. Unternehmen zahlten für Reservekapazitäten, die oft ungenutzt blieben. Mit dem Aufkommen von Cloud-nativen Datenbankdiensten entstand der Wunsch, dieses Modell zu flexibilisieren. Die Idee, Rechenleistung wie Strom aus der Steckdose zu beziehen – also nur bei tatsächlichem Bedarf – wurde zum Leitbild. Serverless-Datenbanken sind die logische Konsequenz aus dem Wunsch, die operative Komplexität zu senken. Die Vorgeschichte zeigt, dass die IT-Abteilungen zunehmend unter dem Druck standen, Kosten zu senken und gleichzeitig die Agilität zu erhöhen. Serverless versprach den 'Heiligen Gral': Weniger Administration bei gleichzeitig geringeren Kosten durch eine präzise Abrechnung nach Verbrauch.

Die Beteiligten: Akteure und systemische Abhängigkeiten

Die Entscheidung für oder gegen ein Serverless-Modell betrifft primär IT-Teams und Systemarchitekten, die für die Stabilität und Kostenstruktur interner Portale verantwortlich sind. Sie sind es, die die Kapazitätsplanung bisher manuell durchführen mussten und nun abwägen müssen, ob sie die Kontrolle an den Cloud-Anbieter abgeben. Die Äußerungen von Experten wie Fabian Deitelhoff verdeutlichen, dass hierbei eine Verschiebung der Verantwortung stattfindet. Serverless löst zwar reale Probleme der Überdimensionierung, verschiebt jedoch die Komplexität in andere Bereiche des Systems. Anstatt sich um die Hardware-Skalierung zu kümmern, müssen sich Entwickler nun verstärkt mit dem Verhalten der Datenbank bei Kaltstarts, der Verbindungsverwaltung und den komplexen Preismodellen der Anbieter auseinandersetzen. Die Entscheidung liegt somit nicht mehr nur in der Wahl der Datenbank-Engine, sondern in der Bewertung des gesamten Ökosystems, das der Anbieter bereitstellt. Es ist ein Abwägungsprozess zwischen der Bequemlichkeit einer automatisierten Plattform und der notwendigen Kontrolle über die Performance-Charakteristika der Anwendung.

Einordnung: Was das Modell wirklich bedeutet

Einzuordnen ist das Serverless-Modell als eine Verlagerung der Komplexität, nicht als deren vollständige Beseitigung. Den Berichten zufolge ist die Technologie zwar ein mächtiges Werkzeug, um Leerlaufkosten zu vermeiden, doch die Annahme, dass Serverless automatisch für jedes Szenario die beste Wahl ist, wäre ein Trugschluss. Die Effizienz hängt stark von der Lastcharakteristik der jeweiligen Anwendung ab. Bei Systemen mit einer sehr konstanten und hohen Last kann ein klassisches Instanz-Modell unter Umständen sogar kostengünstiger und berechenbarer sein als ein Serverless-Tarif, der bei hoher Auslastung durch die Abrechnung nach Anfragen oder I/O-Operationen teurer werden kann. Die Einordnung der Technologie erfordert daher eine genaue Analyse des Workloads. Wer die Architektur nicht auf die spezifischen Eigenheiten von Serverless-Datenbanken – wie etwa die Latenz beim Aufwachen oder die Verbindungsdichte – ausrichtet, läuft Gefahr, zwar Infrastrukturkosten zu sparen, aber an anderer Stelle durch Performance-Einbußen oder unerwartete Kostenspitzen wieder zu verlieren. Es handelt sich um eine Verschiebung der Entscheidungsebene von der Hardware-Ebene hin zur Anwendungs- und Kostenoptimierungsebene.