Cloudflare D1 erklärt: serverloses SQLite für deine Inhalte

Du schaust dir EmDash an, liest „Inhalte liegen in D1” und willst wissen, was das konkret bedeutet, bevor du ihm deine Website anvertraust. Ist D1 eine richtige Datenbank? Taugt SQLite für den Produktivbetrieb? Wo sind die Grenzen, und wann geht es schief? Berechtigte Fragen. Beantworten wir sie klar.

Was D1 ist, in einem Satz

Cloudflare D1 ist eine serverlose SQLite-Datenbank, also eine echte SQL-Datenbank, die Cloudflare für dich betreibt und skaliert und die direkt neben deinen Cloudflare Workers liegt, damit dein Code sie abfragen kann, ohne dass du einen Datenbankserver verwaltest.

Zwei Wörter darin verdienen eine Erläuterung: SQLite und serverlos.

SQLite, ja, genau dieses SQLite, und ja, es ist ernst zu nehmen

SQLite gilt als die „kleine” Datenbank, die in deinem Telefon, deinem Browser, deinem Auto steckt. Dieser Ruf wird ihr nicht gerecht. SQLite gehört zu den am weitesten verbreiteten und am härtesten erprobten Softwarestücken der Welt, es ist wirklich schnell, und es spricht Standard-SQL: Tabellen, Indizes, Joins, Transaktionen, alles dabei.

Was es traditionell nicht war: eine vernetzte Datenbank über mehrere Maschinen. Klassisches SQLite ist eine Datei auf einer Platte, gelesen und geschrieben von einem Prozess. Für eingebettete Zwecke perfekt, für eine globale Webanwendung unpraktisch, und genau dieses Problem löst D1.

Serverlos, Cloudflare betreibt das SQLite für dich

D1 nimmt SQLite und verpackt es als verwalteten, serverlosen Dienst:

• Kein Server zu betreiben. Du richtest keine Datenbankmaschine ein und patchst sie nicht. Du legst eine Datenbank an und fragst sie aus deinem Worker ab.
• Bereitstellung bei Bedarf. Bei EmDash legt wrangler die D1-Datenbank beim ersten Deploy für dich an, es gibt keinen separaten Schritt „erst mal Postgres aufsetzen”.
• Skalierung bis auf nichts. Wie bei Workers kostet dich eine untätige Datenbank keinen laufenden Server.

Du bekommst also Tempo und Schlichtheit von SQLite, dazu das Betriebsmodell „über einen Datenbankserver muss ich gar nicht nachdenken”.

Wann D1 hervorragend passt

Die Stärke von D1 ist klar umrissen, und eine Inhaltsseite liegt mitten darin:

• Leselastige Arbeitslasten. Websites, die weit mehr lesen als schreiben, also Blogs, Dokumentationen, Marketingseiten und die meisten CMS, sind ideal. Lesen ist das, was D1 am schnellsten kann.
• Mäßiges Schreibvolumen. Einen Beitrag veröffentlichen, Inhalte bearbeiten, gelegentlich ein abgeschicktes Formular, alles unproblematisch.
• Daten, die bequem in eine SQLite-Form passen. Strukturierte, relationale Inhalte. Genau das, was ein CMS speichert.

Wenn deine Anwendung überwiegend liest, vernünftige Schreibraten hat und mit einer einzelnen logischen SQLite-Datenbank auskommt, ist D1 eine starke und einfache Wahl.

Die Grenzen, seien wir ehrlich

Keine Datenbank ist Magie, und D1 hat echte Kanten, die du vor einer Wette darauf kennen solltest:

• Obergrenze bei der Größe. Eine einzelne D1-Datenbank endet bei rund 10 GB. Das ist sehr viel Textinhalt, denk an viele Tausend Artikel, aber eben nicht unbegrenzt. Riesige Datenbestände brauchen einen anderen Plan (oder eine Aufteilung auf mehrere Datenbanken).
• Gleichzeitige Schreibvorgänge. Das Modell von SQLite bevorzugt das Lesen, sehr viele parallele Schreibzugriffe sind nicht seine Stärke. Ein CMS stößt selten daran, ein schreibintensiver Analytics-Feuerwehrschlauch schon.
• Es ist SQLite, nicht Postgres. Keine Postgres-spezifischen Erweiterungen, keine gespeicherten Prozeduren im Sinne von PL/pgSQL. Wenn du auf fortgeschrittene Postgres-Funktionen angewiesen bist, ist D1 kein Eins-zu-eins-Ersatz.
• Noch im Reifen. Für eine verwaltete Datenbank ist D1 vergleichsweise jung. Für ihr Kerngebiet ist sie produktionsreif, aber sie ist keine jahrzehntealte Postgres-Installation.

Die ehrliche Zusammenfassung: Für eine Inhaltsseite wird dich vermutlich keine dieser Grenzen beißen. Für eine schreibintensive Anwendung im Terabyte-Bereich ist D1 das falsche Werkzeug, und das ist in Ordnung, es will das gar nicht sein.

Wie EmDash D1 für deine Inhalte nutzt

EmDash, Cloudflares Open-Source-CMS, speichert seine strukturierten Inhalte und Metadaten in D1. Weil Inhalte als portables JSON vorliegen und nicht als HTML-Klumpen, lassen sie sich natürlich auf SQL-Tabellen abbilden: Beiträge, Felder, Taxonomie, Beziehungen. Ruft jemand eine Seite auf, fragt der Worker D1 direkt daneben ab, ohne Sprung über das Netz zu einer fernen Datenbank, und rendert die Seite am Netzwerkrand.

Die Entwicklererfahrung ist bewusst langweilig, und genau das ist der Punkt:

# EmDash richtet D1 beim ersten Deploy für dich ein, du kannst eine
# Datenbank aber auch direkt mit wrangler anlegen und inspizieren:
npx wrangler d1 create my-site-db
npx wrangler d1 execute my-site-db --command "SELECT count(*) FROM posts;"

Beim allerersten Deploy wendet EmDash seine Schema-Migrationen bei der ersten Anfrage automatisch an, du musst also kein SQL von Hand ausführen, um loszulegen. Der komplette Ablauf steht im Leitfaden zum Deployment von EmDash auf Cloudflare.

Warum diese Paarung für ein CMS so gut funktioniert:

• Die Inhalte liegen neben der Rechenleistung. Worker und D1 im selben Edge-Netzwerk bedeuten schnelle Abfragen ohne Umweg zu einer entfernten Datenbank.
• Leselastig ist das Heimspiel von D1. Inhalte auszuliefern besteht überwiegend aus Lesezugriffen, genau darauf ist D1 optimiert.
• Die Grenze von 10 GB ist für Text riesig. Ein Blog oder eine Dokumentationsseite speichert Jahre an Inhalten und kommt nicht annähernd heran.
• Kein Datenbankbetrieb. Kein Postgres, das du dimensionieren, patchen, von Hand sichern oder nachts um drei am Leben halten musst.

Wo D1 im Gesamtbild steht

D1 ist eines von drei Beinen des serverlosen Stacks, auf dem EmDash steht:

• Workers führen den Code am Netzwerkrand aus.
• D1 hält die strukturierten Inhalte.
• R2 speichert Dateien und Medien (ohne Egress-Gebühren).

Jedes davon ist serverlos und skaliert auf null, eine kleine Website kostet also fast nichts, und eine stark besuchte skaliert, ohne dass du die Architektur umbauen musst. Aus demselben Grund läuft Cloudflares eigener Blog auf diesem Stack und hat einen DDoS mit 28.000 Anfragen pro Sekunde ohne Drama weggesteckt.

Wenn du EmDash prüfst und dir Sorgen machst, „SQLite kann doch nicht ernst gemeint sein”, lautet die ehrliche Antwort: Für eine Inhaltsseite ist es das absolut, und D1 liefert dir das Tempo von SQLite ganz ohne Serverbetreuung.

Wir schreiben darüber, weil unsere Leser danach fragen. Was wir bei 2emdash tatsächlich tun: Wir bauen alternde Websites auf Cloudflare neu und geben den Besitzern ein einfaches Panel an die Hand. Wir sind ein unabhängiger Dienst, nicht verbunden mit Cloudflare oder dem EmDash-Projekt.