Datenbanken ziehen an den Rand – Turso, Neon und Cloudflare D1 schreiben neu, wo Ihre Daten leben

Für den Großteil der Datenbankgeschichte hatte die Frage, wo Ihre Datenbank lebt, eine einfache Antwort: in einem Rechenzentrum, wahrscheinlich in ein oder zwei Regionen für Redundanz, erreichbar für Ihre Anwendungsserver über ein schnelles privates Netzwerk. Die Datenbank ist zentral. Alles verbindet sich mit ihr. Die Latenz zwischen Ihrer App und Ihrer Datenbank wird in Submillisekunden-Netzwerk-Hops innerhalb derselben Einrichtung gemessen.

Das Problem mit diesem Modell ist, dass es nicht berücksichtigt, wo Ihre Nutzer sind. Wenn Ihre App-Server in us-east-1 sind und ein Nutzer in Singapur eine Anfrage stellt, reist diese Anfrage von Singapur nach Virginia und zurück – etwa 200 Millisekunden Round-Trip-Latenz, bevor Sie überhaupt an Datenbankabfragen gedacht haben. Moderne Serverless-Plattformen und Edge-Runtimes haben Anwendungscode näher an die Nutzer gebracht: Cloudflare Workers läuft an über 300 Standorten, Vercel Edge Functions werden in Dutzenden von Regionen bereitgestellt. Aber die meisten Apps fragen immer noch eine einzelne Postgres- oder MySQL-Instanz ab, die in einer Region sitzt, und machen den Latenzvorteil der Edge-Ausführung zunichte, sobald ein Datenbankaufruf erfolgt.

Edge-Datenbanken versuchen, dies zu lösen, indem sie die Daten selbst – oder zumindest häufig abgerufene Daten – näher an die Nutzer bringen.

Die Hauptakteure

Turso basiert auf libSQL, einem Fork von SQLite mit Replikation. Die Architektur ist unkompliziert: Eine primäre Datenbank speichert die autoritative Kopie Ihrer Daten, und Turso repliziert sie automatisch an Edge-Standorte nahe Ihrer Nutzer. Leseabfragen treffen auf die nächste Replica; Schreibvorgänge gehen an die primäre. Turso hat Edge-Replicas in Dutzenden von Regionen bereitgestellt und lässt die ganze Sache aus Entwicklerperspektive wie eine standardmäßige SQLite-Verbindung aussehen. Das Preismodell ist aggressiv – ein großzügiger Free-Tier, dann Preise pro Datenbank. Für Anwendungen mit vielen isolierten Mandanten (SaaS-Produkte, bei denen jeder Kunde seine eigene Datenbank erhält) ist Tursos Modell überzeugend: Sie können Tausende von Datenbanken für sehr wenig Geld haben, jede in der Nähe ihres primären Nutzers positioniert.

Neon verfolgt einen anderen Ansatz: Es ist serverloses Postgres, mit getrenntem Speicher und Rechenleistung. Die Rechenleistung skaliert bei Nichtgebrauch auf Null (wodurch Leerlaufkosten entfallen) und skaliert innerhalb von Sekunden hoch, wenn Traffic eintrifft. Die Speicherschicht ist dauerhaft, mehrinstanzenfähig und global auf Blockebene repliziert. Read Replicas können in jeder Region bereitgestellt werden. Das Entwicklererlebnis ist dem von standardmäßigem Postgres sehr ähnlich – Connection Strings, psql, die gesamte übliche Tooling funktioniert –, was die Migrationshürde deutlich senkt. Neons Branching-Funktion, die sofortige Copy-on-Write-Snapshots Ihrer Datenbank für Entwicklung oder Tests erstellt, wurde weithin gelobt.

Cloudflare D1 basiert ebenfalls auf SQLite und ist tief in Cloudflare Workers integriert. Der Pitch ist einfach: Ihr Worker-Skript läuft am Edge, und D1 ist direkt dabei. Für Abfragen, die keine globale Konsistenz erfordern, eliminiert D1 den Round-Trip zu einer zentralen Datenbank vollständig. D1 ist derzeit im Funktionsumfang im Vergleich zu einem vollwertigen Postgres eingeschränkt – keine Unterstützung für Fremdschlüssel von Haus aus, beschränkt auf das Typsystem von SQLite –, aber es ist für Lesevorgänge wirklich schnell, wenn es mit dem Edge-Worker zusammenarbeitet, der die Anfrage bearbeitet.

PlanetScale verdient eine Erwähnung aus einem anderen Grund: Es kündigte 2024 an, seinen Free-Tier zu beenden und sich wieder auf Unternehmenskunden zu konzentrieren. Mehrere Entwickler, die Projekte auf PlanetScales MySQL-kompatiblem Dienst aufgebaut hatten, mussten schnell migrieren, und viele landeten bei Neon oder Turso. PlanetScales Vitess-basierte Architektur bot horizontale Skalierung zu einem Preis, der sich als nicht nachhaltig erwies. Die Episode war eine nützliche Erinnerung daran, dass Free-Tier-Datenbankdienste keine garantierte Grundlage sind.

Das Konsistenzproblem

Edge-Datenbanken machen einen echten Tradeoff: Die Verteilung von Daten für Lesezugriffe mit geringer Latenz erschwert die Garantie starker Konsistenz. Dies ist kein neues Problem – das CAP-Theorem ist seit zwei Jahrzehnten ein fester Bestandteil der Ausbildung zu verteilten Systemen –, aber es wird in den Designs von Edge-Datenbanken auf eine Weise konkret, die es zu verstehen lohnt.

Mit Tursos Edge-Replicas kann ein an der primären ausgeführter Schreibvorgang einige hundert Millisekunden dauern, bis er sich auf alle Edge-Replicas ausgebreitet hat. Wenn ein Benutzer Daten schreibt und sie sofort wieder liest, und der Lesezugriff auf eine Replica trifft, die den Schreibvorgang noch nicht erhalten hat, sehen sie veraltete Daten. Für viele Anwendungen – einen Blog, einen Produktkatalog, einen Social Feed – ist dies akzeptabel. Für Anwendungen, bei denen Konsistenz kritisch ist – eine Finanztransaktion, eine Bestandsaktualisierung mit harten Einschränkungen – ist es das nicht.

Neon handhabt dies anders. Seine Read Replicas können synchron (garantierte Konsistenz) oder asynchron (geringere Latenz, potenziell veraltet) konfiguriert werden. Die meisten Anwendungen können asynchrone Replicas für leseintensive Pfade verwenden und Schreibvorgänge sowie latenzempfindliche Lesezugriffe an die primäre leiten. Die Architektur ist flexibler als die von Turso, erfordert aber explizitere Überlegungen dazu, welche Abfragen welches Konsistenzniveau benötigen.

Cloudflare D1s Konsistenzmodell ist auf eine einzelne Region beschränkt: Schreibvorgänge auf D1 sind für Lesezugriffe in derselben Region sofort sichtbar, aber globale Konsistenz ist nicht garantiert. Cloudflares Durable Objects bieten ein anderes Primitiv für global konsistenten Zustand, aber Durable Objects sind keine relationale Datenbank.

Die SQLite-Konvergenz

Ein auffälliges Muster in der Edge-Datenbanklandschaft ist, wie viele dieser Produkte auf SQLite als zugrundeliegende Speicher-Engine konvergieren. Turso's libSQL, Cloudflare D1, Buns eingebaute Datenbank und mehrere andere verwenden SQLite oder einen Ableger. Die Gründe sind praktisch: SQLite ist extrem schnell für Single-Writer-Workloads, es ist in den Anwendungsprozess eingebettet (kein separater Server), und es ist außergewöhnlich gut getestet. Die Herausforderung war schon immer die Replikation, die das standardmäßige SQLite nicht unterstützt – libSQL, LiteFS und ähnliche Projekte arbeiten daran, diese Lücke zu schließen.

Die Entstehung von SQLite als ernstzunehmende Produktionsdatenbank-Engine – über seine traditionelle Rolle als eingebetteter lokaler Speicher hinaus – ist einer der interessanteren Infrastrukturtrends der letzten Jahre. Es läuft auf allem von IoT-Geräten bis hin zu serverlosen Edge-Funktionen, und seine Einfachheit wird zunehmend als Feature und nicht als Einschränkung angesehen.

Wann man es einsetzen sollte

Edge-Datenbanken sind eine gute Wahl für Anwendungen, bei denen Nutzer global verteilt sind, leseintensive Workloads die Norm sind und Eventual Consistency für die meisten Abfragen akzeptabel ist. SaaS-Produkte mit datenbankpro Mandant, Inhaltsplattformen mit globalem Publikum und API-Backends, die mobile Apps in vielen geografischen Regionen bedienen, sind alles sinnvolle Kandidaten.

Sie sind eine schlechtere Wahl für Anwendungen mit komplexen Transaktionen, strengen Konsistenzanforderungen über viele Nutzer hinweg oder schweren analytischen Workloads. Ein Finanzledger, ein E-Commerce-Bestandssystem mit hohen gleichzeitigen Schreibvorgängen oder ein Data Warehouse sollten wahrscheinlich bei einer konventionellen zentralisierten Datenbank bleiben – zumindest bis das Edge-Datenbank-Ökosystem weiter ausgereift ist.

Der zugrundeliegende Druck, der diesen Wandel vorantreibt, wird nicht verschwinden: Nutzer erwarten schnelle Anwendungen, und schnelle Anwendungen benötigen Daten in der Nähe der Nutzer. Die Kategorie der Edge-Datenbanken ist noch jung, die Tooling ist weniger ausgereift als bei zentralisiertem Postgres, und es gibt noch einige Kanten, die rau sind. Aber für den richtigen Workload ist die Latenzverbesserung greifbar und real – und so beginnt normalerweise die Einführung von Infrastruktur.