Eine neue Ära der Datenbanken: Lakebase

Seit Jahrzehnten sind Datenbanken das Rückgrat der Software: Sie treiben im Stillen alles an, von E-Commerce-Checkout-Prozessen bis hin zur Enterprise-Resource-Planning. Jedes Softwarestück der Welt, jede Anwendung, jeder Workflow, jede KI-generierte Codezeile hängt letztendlich von einer darunterliegenden Datenbank ab. Auf diesem Weg haben wir die Art und Weise, wie Anwendungen erstellt werden, komplett neu erfunden, aber die zugrunde liegenden Datenbanken haben sich seit den 1980er Jahren kaum verändert. Sie bauen größtenteils auf Architekturen auf, die der modernen Cloud vorausgehen, und leiden unter Folgendem:

• Fragile & kostspielige Operationen: Traditionelle Datenbanken gelten als eines der empfindlichsten Infrastrukturteile, und ihr zuverlässiger Betrieb erfordert in der Regel eine Armee von Spezialisten, die "auf Eierschalen laufen". Sie bündeln Rechenleistung und Speicher zu einer starren, monolithischen Einheit. Dies zwingt Teams, für Spitzenkapazitäten zu planen, was zu teuren, ungenutzten Ressourcen führt. Wenn die Last über die bereitgestellte Kapazität hinaus ansteigt, können Datenbanken nicht mehr reagieren. Schlimmer noch: Einfache Wartungsaufgaben wie das Erstellen eines Snapshots einer Datenbank oder das Ausführen einer GDPR-Bereinigungsabfrage können potenziell die gesamte Datenbank lahmlegen.
• Umständliche Entwicklungserfahrung: Traditionelle Datenbanken kollidieren mit den modernen, agilen Entwicklungs-Workflows. Für Code dauert es weniger als eine Sekunde, einen Git-Branch für die Entwicklung zu erstellen, der ein vollständig isolierter Klon der Codebasis ist. Für Datenbanken dauert es viele Minuten, wenn nicht Stunden, um eine bereitzustellen, und das Erstellen eines originalgetreuen Klons der Produktionsdatenbank ist sehr kostspielig und birgt das Risiko, die Produktionsdatenbank lahmzulegen. Der Aufstieg der KI-gesteuerten Entwicklung hat diesen Druck nur noch verstärkt. KI-Agenten müssen sofort temporäre, isolierte Umgebungen für Experimente hochfahren.
• Extremer Vendor Lock-in: Datenbankmigrationen sind eines der beängstigendsten technischen Projekte in jeder Organisation. Die monolithische Architektur bedeutet, dass der einzige Weg, Daten hinein oder heraus zu bekommen, über die Datenbank-Engine selbst führt. Dies führt zu einem erheblichen Vendor Lock-in, der Organisationen stark von dem jeweiligen Anbieter abhängig macht.

Es ist an der Zeit, dass sich Datenbanken weiterentwickeln.

Was ist eine Lakebase?

Es entstehen neue Systeme, die die Einschränkungen traditioneller Datenbanken angehen. Eine Lakebase ist eine neue, offene Architektur, die die besten Elemente von Transaktionsdatenbanken mit der Flexibilität und Wirtschaftlichkeit des Data Lake kombiniert. Lakebases werden durch ein grundlegend neues Design ermöglicht: die Trennung von Rechenleistung und Speicher und die direkte Platzierung der Daten der Datenbank in kostengünstigem Cloud-Speicher ("Lake") in offenen Formaten, während die transaktionale Rechenschicht unabhängig darüber laufen kann.

Diese Trennung ist der entscheidende Durchbruch. Traditionelle Datenbanken bündeln CPU und Speicher zu einem monolithischen System, das als eine einzige große Maschine bereitgestellt, verwaltet und bezahlt werden muss. Lakebase teilt diese Schichten auf. Daten leben offen im Lake, während die Datenbank-Engine zu einer vollständig verwalteten, serverlosen Rechenschicht (z. B. Postgres) wird, die sofort skaliert werden kann. Diese Architektur beseitigt einen Großteil der Kosten, Komplexität und des Lock-in, die Datenbanken seit Jahrzehnten auszeichnen, und sie ist besonders leistungsstark für moderne KI- und agentengesteuerte Workloads, bei denen Entwickler viele Instanzen starten, frei experimentieren und nur für das bezahlen möchten, was sie nutzen.

Eine Lakebase hat die folgenden Hauptmerkmale:

Speicher ist von Rechenleistung getrennt: Daten werden kostengünstig in Cloud-Objektspeichern ("Lake") gespeichert, während die Rechenleistung unabhängig und elastisch läuft. Dies ermöglicht massive Skalierung, hohe Parallelität und die Möglichkeit, in weniger als einer Sekunde auf Null herunterzuskalieren (was in Legacy-Datenbanksystemen nicht möglich ist), wodurch die Notwendigkeit entfällt, teure Datenbankmaschinen im Leerlauf laufen zu lassen.

Unbegrenzter, kostengünstiger, dauerhafter Speicher: Da sich die Daten im Lake befinden, wird der Speicher im Wesentlichen unendlich und dramatisch billiger als bei traditionellen Datenbanksystemen, die eine Infrastruktur mit fester Kapazität erfordern. Und der Speicher wird durch die Dauerhaftigkeit des Cloud-Objektspeichers (z. B. S3) unterstützt, der standardmäßig eine Dauerhaftigkeit von 99,999999999 % bietet. Dies ist der traditionellen Datenbankkonfiguration mit Replikaten für Speicheredundanz weit überlegen (die meist asynchron aktualisiert werden, was bedeutet, dass in vielen Konfigurationen bei Doppelfehlern ein Datenverlust möglich ist).

Elastische, serverlose Postgres-Rechenleistung: Lakebase bietet vollständig verwaltetes, serverloses Postgres, das bei Bedarf sofort hochskaliert und bei Inaktivität herunterskaliert wird. Die Kosten stimmen direkt mit der Nutzung überein, was es ideal für Burst-Workloads, Entwicklungsumgebungen und KI-Agenten macht, die temporäre Instanzen hochfahren.

Sofortiges Branching, Klonen und Wiederherstellen: Datenbanken können verzweigt und geklont werden, wie Entwickler Code verzweigen. Selbst Petabyte-große Datenbanken können in Sekundenschnelle kopiert werden, was schnelles Experimentieren, sichere Rollbacks und sofortige Wiederherstellung ohne betrieblichen Aufwand ermöglicht.

Vereinheitlichte transaktionale und analytische Workloads: Lakebase integriert sich nahtlos in das Lakehouse und teilt sich die gleiche Speicherschicht über OLTP und OLAP hinweg. Dies ermöglicht es, Echtzeit-Analysen, maschinelles Lernen und KI-gesteuerte Optimierung direkt auf Transaktionsdaten auszuführen, ohne diese zu verschieben oder zu duplizieren.

Offen und Multicloud by Design: In offenen Formaten gespeicherte Daten vermeiden proprietären Lock-in und ermöglichen echte Portabilität über AWS, Azure und darüber hinaus. Die integrierte Multicloud-Flexibilität unterstützt Disaster Recovery, langfristige Freiheit und eine stärkere Wirtschaftlichkeit im Laufe der Zeit.

Dies sind die wichtigsten Attribute von Lakebase. Transaktionssysteme der Enterprise-Klasse erfordern zusätzliche Funktionen wie Sicherheit, Governance, Auditing und Hochverfügbarkeit - aber mit einer Lakebase müssen diese Funktionen nur einmal implementiert und verwaltet werden, auf einer einzigen offenen Grundlage. Lakebase stellt die nächste Evolution von Datenbanken dar: Transaktionssysteme, die für die Cloud, für Entwickler und für das KI-Zeitalter neu aufgebaut wurden.

Evolution der Datenbankarchitektur

Um zu verstehen, warum eine neue Ära erforderlich ist, ist es hilfreich zu betrachten, wie sich die Datenbankarchitektur in den letzten fünfzig Jahren entwickelt hat. Wir betrachten diese Entwicklung in drei verschiedenen Generationen:

Generation 1: Monolith

Beispiele: MySQL, Postgres, klassisches Oracle

Datenbanksysteme begannen als absolute Monolithen. In der Zeit vor der Cloud war das Netzwerk der langsamste Teil jedes Systems. Die einzige Möglichkeit, eine hochleistungsfähige Datenbank zu entwerfen, bestand darin, die Rechenleistung (CPU/RAM) und den Speicher (Festplatte) innerhalb einer einzigen physischen Maschine fest miteinander zu verbinden. Dies war zwar für die Hardwarebeschränkungen der 1980er Jahre sinnvoll, schuf aber einen starren Käfig, in dem Daten in proprietären Formaten gefangen waren und Skalierung bedeutete, eine größere Box zu kaufen.

Generation 2: Proprietäre lose Kopplung des Speichers

Beispiele: Aurora, Oracle Exadata

Als sich die Cloud-Infrastruktur verbesserte, trennten die Anbieter den Speicher physisch von der Rechenleistung und verlagerten den Speicher in proprietäre Backend-Tiers. Diese Systeme waren technische Meisterleistungen, die die Grenzen des Durchsatzes verschoben. Aber sie gingen nicht weit genug. Die Trennung war rein eine interne Optimierung. Da die Daten in einem proprietären Format eingeschlossen bleiben, auf das nur eine einzige Engine zugreifen kann, leiden Systeme der 2. Generation unter strukturellen Sackgassen:

• Single Engine Chokehold: Auf Daten kann nur über die primäre Datenbank-Engine zugegriffen werden, die zum Engpass wird. Für KI-Agenten oder Analyse-Engines, die in großem Umfang auf die Daten zugreifen, ist dies schwierig.
• Analytische Reibung: Da Sie keine separaten OLAP-Engines direkt in großem Umfang auf die Datenbankdateien zugreifen lassen können, bleibt die Ausführung analytischer Abfragen schwierig und erfordert in der Regel komplexe ETL, um Daten herauszubewegen.
• Cloud Lock-in: Die Speicherschicht ist oft eng mit der proprietären Infrastruktur des jeweiligen Cloud-Anbieters verbunden. Dies erschwert die Multicloud-Interoperabilität und macht echte Cross-Cloud High Availability und Disaster Recovery (HADR) unmöglich. Wenn die Region des Anbieters ausfällt, bleiben Ihre Daten stecken.

Wir glauben, dass sich diese Systeme in einem Übergangsstadium zur ultimativen 3. Generation befinden.

Generation 3: Lakebase - Offener Speicher auf dem Lake

Eine Lakebase führt die entkoppelte Architektur zu ihrem ultimativen, logischen Schluss. Wie Gen 2 trennt sie Rechenleistung von Speicher, aber mit einem entscheidenden Unterschied: sowohl die Speicherinfrastruktur als auch die Datenformate sind vollständig offen.

Aufbauend auf dieser Architektur kann sie die oben genannten 3 Herausforderungen lösen:

• Bessere Zuverlässigkeit und niedrigere Kosten durch einfachere Operationen: Häufige Operationen wie Bereitstellung, Hochskalieren, Herunterskalieren, Branching, Snapshotting, Wiederherstellung können in Sekundenschnelle abgeschlossen werden. Teure Abfragen können auf verschiedenen elastischen Recheninstanzen ausgeführt werden, ohne den Produktionsverkehr zu beeinträchtigen.
• Git-ähnliche Entwicklungserfahrung: Es wird schneller, Anwendungen zu experimentieren und zu entwickeln, basierend auf einem originalgetreuen Branch der Produktionsdatenbanken. Für Entwickler und KI-Agenten bedeutet dies, dass sich die Datenbank so schnell bewegt wie ihr Code.
• Löst extremen Vendor Lock-in: Da sich Daten in offenen Formaten befinden, die in Cloud-Objektspeichern gespeichert sind, sind Sie viel weniger abhängig. Sie besitzen Ihre Daten, unabhängig von der Engine.

In vielerlei Hinsicht ist eine Lakebase das, was Sie bauen würden, wenn Sie OLTP-Datenbanken heute neu entwerfen müssten, jetzt, da billiger, zuverlässiger Objektspeicher und Cloud-Elastizität verfügbar sind. Da sich Unternehmen durch die Einführung von Cloud und KI schneller bewegen, erwarten wir, dass dieses Modell zu einer Standardgrundlage für den Aufbau von Transaktionssystemen wird.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag