In der heutigen digitalen Welt wachsen die Anforderungen an Datenbanken ständig. Unternehmen benötigen Lösungen, die nicht nur hohe Leistungsfähigkeit bieten, sondern auch nahtlos mit den dynamischen Anforderungen von Cloud-Umgebungen skalieren können. Amazon Web Services (AWS) hat mit Aurora DSQL eine Antwort auf diese Herausforderungen geschaffen und gleichzeitig eine spannende technologische Entwicklung eingeleitet, die zeigt, wie moderne Programme und Architekturen die Datenbanklandschaft verändern. Aurora DSQL ist mehr als nur ein weiteres Produkt im Portfolio relationaler Datenbanken. Es steht für eine grundlegend neue Herangehensweise an die Skalierung und Handhabung von Datenbanken in der Cloud.
Seit der Vorstellung bei re:Invent 2024 hat das Aurora DSQL-Team intensiv mit Entwicklern und Ingenieuren zusammengearbeitet, um das Potenzial von serverlosen, verteilten Datenbanken voll auszuschöpfen. Dabei wurde deutlich, dass die Herausforderungen nicht nur in der Technologie selbst liegen, sondern vor allem im Prozess des Hinterfragens etablierter Methoden und dem mutigen Einsatz innovativer Lösungen. Ein wesentlicher Treiber für Aurora DSQL war die wachsende Komplexität der Kundenanforderungen. Während traditionelle relationale Datenbanken lange Zeit die Basis vieler Anwendungen bildeten, reicht ihre konventionelle Architektur heute oft nicht mehr aus, um mit der Skalierung und den Performance-Erwartungen großer Datenmengen Schritt zu halten. Frühe Lösungen von AWS wie Amazon RDS vereinfachtem zwar das Management solcher Datenbanken, doch immer dringlicher wurden maßgeschneiderte Systeme, die speziell auf bestimmte Workloads ausgerichtet sind.
DynamoDB für NoSQL-Anwendungen, Redshift für analytische Abfragen und Aurora selbst für kosteneffektive, performante relationale Datenbanklösungen zeigen, wie divers die Datenbanklandschaft sein muss, um den unterschiedlichen Bedürfnissen gerecht zu werden. Aurora DSQL setzt genau hier an – mit dem Ziel, eine vollständig serverlose relationale Datenbank zu bieten, die ohne Infrastrukturmanagement auskommt und automatisch horizontal skaliert. Die Kombination von funktionsreicher SQL-Unterstützung mit echter Multi-Region-Fähigkeit und null operativem Aufwand stellt einen Paradigmenwechsel dar. Um dies zu erreichen, wurde die Datenbank nicht länger als monolithisches System gedacht, sondern in modularisierte, gut definierte Komponenten aufgesplittet. Dieser Ansatz folgt dem klassischen Unix-Mantra „Eine Sache richtig machen“, wobei die einzelnen Module zusammenarbeiten, um alle benötigten Datenbankfunktionen zu gewährleisten.
Eine der größten Herausforderungen war dabei die Skalierung des Schreibpfads. Während das horizontale Skalieren von Lesevorgängen bereits 2021 gelöst wurde, blieben effizientes und gleichzeitig atomar sicheres Schreiben über verteilte Komponenten hinweg schwierig. Konventionelle Verfahren wie Two-Phase Commit (2PC) stoßen schnell an ihre Grenzen, wenn Transaktionen mehrere getrennte Speicher-Teile gleichzeitig aktualisieren müssen. Die Koordination dieser Vorgänge erzeugt nicht nur hohe Komplexität, sondern führt auch zu Latenzspitzen und Verfügbarkeitsproblemen. Statt einzelne Datenbereiche vorgängig an unterschiedliche Journal-Knoten zu binden, wie es viele Systeme tun, entschied sich das Team von Aurora DSQL für eine radikale Neuausrichtung: Jede komplette Transaktion wird in einem einzigen Journal niedergeschrieben, unabhängig davon, wie viele Zeilen betroffen sind.
Dadurch werden atomare und dauerhafte Anforderungen von ACID-Transaktionen erfüllt, und das Schreiben lässt sich einfacher skalieren. Natürlich führt diese Entscheidung zu einer zusätzlichen Herausforderung auf dem Leseweg, da zum aktuellen Zustand einer einzelnen Zeile nun alle Journale konsultiert werden müssen, um die neuesten Updates zu ermitteln. Um dieses Problem zu lösen, wurde eine innovative Komponente namens Crossbar entwickelt. Die Crossbar bietet dem Storage-System eine Abonnement-API, mit der sich einzelne Speicher-Knoten für Key-Ranges anmelden können. Wenn neue Transaktionen ankommen, leitet die Crossbar genau die relevanten Updates an die entsprechenden Speicherknoten weiter.
Das Konzept ist elegant, aber die Implementierung anspruchsvoll, insbesondere weil die Crossbar stets die totale Reihenfolge aller Transaktionen garantieren muss. Diese Verteilung und parallele Verarbeitung führt jedoch in der Praxis zu Problemen, wenn einzelne Knoten Verzögerungen haben – was häufig durch Garbage Collection in JVM-basierten Umgebungen verursacht wird. Solche Verzögerungen können die Gesamtperformance drastisch verschlechtern, da jeder Knoten potenziell den Engpass in der Kette darstellt. Simulationen zeigten, dass bei etwa 40 Knoten anstelle der erwarteten Millionen von Transaktionen pro Sekunde nur einige Tausend erreicht wurden, und dass Tail-Latenzen inakzeptabel anstiegen. Angesichts dieser Problemstellungen stellte sich die Frage, wie eine Cloud-Datenbank mit hohen Anforderungen an Durchsatz, Verfügbarkeit und niedrige Latenzen gebaut werden kann.
Die herkömmliche JVM-Plattform mit Garbage Collector zeigte für diesen Anwendungsfall fundamentale Limitierungen. Eine Reduzierung des Garbage-Collectors durch noch tiefere Optimierung erschien zu riskant und komplex. C und C++ als Alternativen boten Kontrolle, aber auf Kosten der Speicher- und Sicherheitsgarantien. Die Wahl fiel auf Rust, eine moderne Programmiersprache, die garantiert speichersicher arbeitet und keine Laufzeit-Garbage-Collector-Pauses verursacht, ohne dass Entwickler auf Performance verzichten müssen. Der Umstieg auf Rust begann mit einem kleinen, aber wesentlichen Teil des Systems – dem Adjudicator.
Diese Komponente entscheidet, welche Transaktion bei Konflikten gewinnt, und bildet somit eine kritische Funktion vor dem Journal-System. Interessanterweise kamen zwei Entwickler, die keinerlei Erfahrung mit Rust oder niedrigeren Sprachen hatten, sehr schnell zu überraschend guten Ergebnissen. Ohne zielgerichtete Optimierung erzielten sie mit Rust eine zehnfache Performance-Steigerung gegenüber einer langjährig optimierten Kotlin-Implementierung. Dieses schnelle Erfolgserlebnis überzeugte das Team, Rust auch für die gesamte Datenebene zu verwenden. Dabei wurde eine weitere wichtige Erkenntnis gewonnen: Der Wechsel zu Rust im Datenpfad bedeutet nicht zwingend, die gesamte Codebasis umzuschreiben.
Das Team entschied sich, die Steuerungsebene weiterhin in Kotlin zu belassen, da dort andere Anforderungen und langfristige Produktivitätsaspekte dominierten. Allerdings zeigte die spätere Integration der beiden Sprachen die Grenzen dieser Strategie auf. Die Gleichzeitigkeit von Logik in Kotlin und Rust führte zu Inkonsistenzen, Dopplungen und erschwerte Wartbarkeit und Testbarkeit. Nach intensiven Überlegungen wurde deshalb auch die Steuerungsebene auf Rust umgestellt, was die Entwicklung weiter vereinfachte und die Performance stabilisierte. Eine weitere spannende Herausforderung war die Integration mit PostgreSQL.
Aurora DSQL baut auf PostgreSQL als bewährtem System für Abfrageverarbeitung auf, verwendet jedoch eigene hochoptimierte Komponenten für Speicherung, Replikation und Transaktionsmanagement. Anstatt einen harten Fork von PostgreSQL zu erstellen, der Wartung und Weiterentwicklung komplex macht, nutzte das Team die Extensibilität von PostgreSQL. Über definierte Schnittstellen und Extension Points lassen sich Anpassungen vornehmen, ohne den Ursprungscode zu verändern – eine clevere und nachhaltige Lösung. Die Erweiterungsentwicklung profitierte ebenfalls vom Einsatz von Rust. Obwohl das PostgreSQL-Kernsystem in C geschrieben ist, erkannte das Team, dass neu hinzugefügter Code wegen der Risiken von Speicherfehlern genau dort besonders kritisch ist.
Durch die Verwendung von Rust für die Extensions können Speicher-Sicherheitsfehler wie Buffer Overruns oder Use-After-Free praktisch ausgeschlossen werden. So sorgt Rust nicht nur für bessere Performance, sondern auch für weniger Fehler, was langfristig sowohl Kosten als auch Risiken senkt. Die Entscheidung für Rust als zentrale Technologie in Aurora DSQL zeigt exemplarisch, wie technische Entscheidungen nicht nur von unmittelbarem Profit, sondern vor allem von langfristiger Wartbarkeit, Sicherheit und Wachstumspotenzial bestimmt werden sollten. Die Lernkurve für ein neues System wie Rust mag zwar zunächst steil sein, doch der daraus resultierende Zugewinn an Effizienz und Verlässlichkeit erweist sich als großer Gewinn. Neben den technischen Aspekten zeigt das Aurora DSQL Projekt auch, wie eine breite, teamorientierte Herangehensweise essentielle Bedeutung für den Erfolg hat.
Interne Schulungen, offene Wissensbasis und die direkte Einbindung von Experten schufen eine Atmosphäre, in der Lernen, Experimentieren und kontinuierliche Verbesserung zum Alltag gehörten. Das förderte nicht nur die Qualität des Codes, sondern auch die Motivation und den Zusammenhalt in den Teams. Heute liefert Aurora DSQL ein starkes Fundament für cloudnative Anwendungen der Zukunft. Es vereint Skalierbarkeit, Automatisierung und hohe Performance mit den vertrauten Vorteilen relationaler Datenbanken. Die Entwicklungsgeschichte dokumentiert dabei eindrucksvoll die Bedeutung von Mut zu neuen Technologien, die Bereitschaft, gewohnte Pfade zu verlassen, und den Wert iterativen Lernens.
Abschließend ist Aurora DSQL beispielhaft für die nächste Generation von Datenbanktechnologien, die den Anforderungen moderner, verteilter Systeme gerecht werden. Die Kombination aus modularer Architektur, der Nutzung von Rust für kritische Komponenten und enger Integration mit bewährten Systemen wie PostgreSQL bietet Entwicklern und Unternehmen eine leistungsstarke, flexible und vor allem zukunftssichere Lösung. Wenn es darum geht, relationale Datenbanken wirklich skalierbar zu machen, zeigt Aurora DSQL eindrucksvoll: Einfach skalieren ist möglich – wenn man traditionelle Denkweisen hinterfragt und neue Wege mutig beschreitet.
