Cloudflare D1: Wann das Free Tier Abfragen stoppt

Seit dem 1. September 2026 ist Cloudflare D1 Free zu einer Entscheidung über die Produktionsverfügbarkeit geworden. Sobald ein Konto an einem Tag entweder 5 Millionen Zeilenlesevorgänge oder 100,000 Zeilenschreibvorgänge verbraucht, können D1-Abfragen bis Mitternacht UTC ausfallen.

Cloudflare D1 ändert den Ausfallmodus, nicht das Kontingent

Die kostenlosen Kontingente gab es bereits. Neu ist, was an ihrer Grenze passiert.

Bei Workers Free führt das Überschreiten eines der beiden Tageskontingente nun dazu, dass D1-Abfragen sowohl über die Workers Binding API als auch über die REST API zurückweist. Cloudflare nennt getrennte Meldungen für das Lese- und das Schreiblimit und erklärt, dass Abfragen wieder funktionieren, sobald das Kontingent um 00:00 UTC zurückgesetzt wird. Die gespeicherten Daten bleiben unversehrt. Die Anwendung kann sie trotzdem möglicherweise weder lesen noch ändern.

Genau darin liegt die entscheidende Änderung: Aus einer unverbindlichen Nutzungskennzahl ist eine harte Verfügbarkeitsgrenze geworden.

Cloudflare verschickt eine E-Mail, sobald das Tageslimit erreicht ist. Sie erklärt zwar die Ursache des Vorfalls, trifft aber erst ein, wenn die Datenbank bereits nicht mehr verfügbar ist. Ein Produktionsteam braucht daher ein Budget und eine frühere Warnung – nicht nur eine nachträgliche Fehlererklärung. Das D1-Changelog vom 1. September enthält das genaue Fehlerverhalten und die Fehlermeldungen.

Workers Paid ist von diesem täglichen Stopp nicht betroffen. Ein Prototyp, der deutlich unter beiden Kontingenten bleibt, muss heute womöglich nicht wechseln. Ein Live-Produkt, das auf D1 angewiesen ist, sollte Free dagegen wie jede andere Ressource mit einem Abschaltpunkt behandeln.

Entscheidend sind die gescannten Zeilen

Das Lesekontingent umfasst weder 5 Millionen API-Aufrufe noch 5 Millionen zurückgegebene Datensätze. Gemeint sind 5 Millionen von der Datenbank beim Bearbeiten der Abfragen gescannte Zeilen.

Angenommen, ein Filter liefert genau einen Kunden zurück, kann aber keinen geeigneten Index nutzen. Dann muss D1 unter Umständen eine Tabelle mit 5,000 Zeilen durchsuchen, um diesen Datensatz zu finden. Wird dieselbe Abfrage 1,000-mal ausgeführt, sind die gesamten 5 Millionen täglichen Zeilenlesevorgänge verbraucht. Das Ergebnis war klein, der Aufwand dahinter nicht.

Schreibvorgänge sind direkter. Bei INSERT, UPDATE oder DELETE zählen die geänderten Zeilen. Ein Einfügevorgang mit 10 Zeilen wird als 10 geschriebene Zeilen gewertet. Auch Schemaoperationen wie CREATE, ALTER und DROP können eine Mischung aus Lese- und Schreibvorgängen verbrauchen.

Die Zeilengröße beeinflusst diesen Zähler nicht. Eine Zeile mit 1 KB und eine mit 100 KB zählen jeweils als eine Zeile. Entscheidend für die Lesezahl ist die Form der Abfrage.

Mit einem Index kann D1 direkt zu den relevanten Datensätzen springen, statt die gesamte Tabelle zu durchsuchen. Dafür fällt meist etwas zusätzliche Schreibarbeit an, während sich die Lesevorgänge erheblich reduzieren. Wird eine von einem Index erfasste Spalte geschrieben, aktualisiert D1 die Tabellenzeile und mindestens eine Indexzeile. Deshalb sollten die Spalten indexiert werden, die häufig in Filtern und Joins vorkommen – nicht wahllos jede Spalte.

Cloudflares Leitfaden zu Indizes liefert einen klaren Test. Der teuren Abfrage wird EXPLAIN QUERY PLAN vorangestellt. Zeigt der Plan SCAN, wird die Tabelle gelesen. Bei SEARCH ... USING INDEX kommt ein Index zum Einsatz. Nach dem Anlegen eines Index sollte PRAGMA optimize ausgeführt werden, damit dem Abfrageplaner aktuelle Statistiken vorliegen.

Die wirtschaftliche Rechnung hat sich verändert

Workers Free kostet weiterhin $0. Verändert hat sich das Risiko: Die maximale Datenbankrechnung bleibt zwar bei null, doch die Datenbank kann die Anwendung nun für den Rest des UTC-Tages nicht mehr bedienen.

Workers Paid beginnt bei $5 pro Konto und Monat. Der tägliche harte Stopp wird dort durch monatlich enthaltene Nutzung und Preise für Mehrverbrauch ersetzt.

Der Sprung von Free zu Paid ist größer, als es zunächst wirkt. Dreißig Tage am Leselimit von Free ergeben insgesamt 150 Millionen Zeilen – lediglich 0.6% der im Paid-Tarif enthaltenen 25 Milliarden Lesevorgänge. Dreißig Tage am Schreiblimit von Free ergeben 3 Millionen Zeilen beziehungsweise 6% der 50 Millionen enthaltenen Schreibvorgänge.

Für viele kleine Anwendungen ist die erste Paid-Entscheidung daher keine Frage des Mehrverbrauchs, sondern eine Verfügbarkeitsentscheidung für $5. Workers-Anfragen, CPU, D1-Speicher oberhalb von 5 GB und weitere Cloudflare-Produkte werden weiterhin separat gemessen. Die $5 sind also die Untergrenze und kein Versprechen, dass das gesamte Konto exakt $5 kostet. Der ausführlichere Cloudflare-Preischeck zeigt, wie Konto- und Produktkosten voneinander abgegrenzt sind.

Für D1 fallen weder Datenübertragungs- noch Durchsatzgebühren an. Das schwächt den Ausfall im Free-Tarif nicht ab. Es bedeutet lediglich, dass Egress bei dieser Entscheidung nicht zu den relevanten Kennzahlen gehört.

Vier Teams, vier konkrete Maßnahmen

Solo-Gründer mit einem produktiven SaaS

Wenn Anmeldung, Abrechnungsstatus oder Kunden-Dashboard Daten aus D1 lesen, trägt der Free-Tarif nun ein Ausfallrisiko für den Produktivbetrieb. Zuerst sollte der geschäftigste normale Tag ermittelt werden, danach sind vollständige Tabellenscans zu beseitigen. Nähert sich die Anwendung anschließend noch immer dem Limit, ist der Mindestpreis von $5 günstiger als eine Planung um eine unbekannte Zahl von Stunden ohne Datenbankzugriff.

Der Nutzen liegt nicht in abstrakt höherer Datenbankkapazität. Entscheidend ist, dass Mitternacht UTC aus dem Wiederherstellungsplan für Störungen verschwindet.

Agentur mit mehreren Datenbanken in einem Konto

Die Limitangaben gelten auf Kontoebene. Eine Agentur sollte deshalb jede D1-Datenbank im betreffenden Cloudflare-Konto erfassen, statt nur ein Kundenprojekt zu prüfen und das gesamte Konto für sicher zu erklären.

Kennzahlen pro Datenbank zeigen das ressourcenintensive Projekt; anschließend werden die Werte addiert, bevor das Kontobudget festgelegt wird. So entsteht eine gemeinsame Kennzahl, für die der Betrieb Verantwortung übernehmen kann. Ein ineffizienter Scan in einem Projekt darf nicht als rätselhafter Ausfall an anderer Stelle desselben Kontos auftauchen.

Backend-Entwickler auf der Suche nach teuren Lesevorgängen

Gesucht werden die kostspieligen Abfragemuster, nicht Daten, die sich wahllos löschen lassen. D1 liefert rows_read und rows_written im meta-Objekt jeder Abfrage. Sie zeigen die genauen Kosten einer einzelnen Ausführung.

Cloudflare stellt Abfrageanalysen außerdem über Wrangler und die GraphQL Analytics API bereit. Eine Sortierung nach Lesevorgängen bringt wiederholte Scans nach oben. Danach folgen Planprüfung, ein gezielter Index und eine erneute Messung. Dieselbe Änderung senkt damit den Kontingentverbrauch und in der Regel auch die Latenz.

Betriebsverantwortlicher für Importe oder Synchronisierungen

Eine Massensynchronisierung kann 100,000 Schreibvorgänge verbrauchen, bevor der Kundendatenverkehr die Datenbank nutzen kann. Ein nicht dringender Auftrag lässt sich über mehrere Rücksetzfenster verteilen; alternativ sollte das Konto vor einem produktiven Import auf Paid umgestellt werden.

Eine Bereinigung nach Erreichen des Schreiblimits ist keine belastbare Strategie. DELETE ist selbst ein Schreibvorgang, sodass dasselbe ausgeschöpfte Kontingent auch die Bereinigungsabfrage bis zum Zurücksetzen blockieren kann. Ziel ist, Live-Schreibvorgänge verfügbar zu halten, während der Batch-Auftrag läuft.

Das Limitbudget festlegen, bevor der Alarm eintrifft

Eine praktikable erste Richtlinie lautet: Für die Produktion werden 80% des veröffentlichten Free-Kontingents eingeplant. Das ist eine Betriebsregel und keine Vorgabe von Cloudflare. Daraus ergibt sich ein tägliches Betriebslimit von 4 Millionen Lese- und 80,000 Schreibvorgängen; 1 Million Lese- und 20,000 Schreibvorgänge bleiben als Reserve für Spitzen und Messverzögerungen.

1. 1

   Den tatsächlichen Tagesverbrauch messen

   In Cloudflare den Bereich D1 öffnen, jede Datenbank auswählen und zu Metrics wechseln. Die Standardansicht zeigt die letzten 24 Stunden. Der betrachtete Verlauf sollte normale Wochentage ebenso abdecken wie Launches, Importe und Lastspitzen. D1 bewahrt diese Kennzahlen 31 Tage lang auf.

2. 2

   Die Abfrage mit dem höchsten Zeilenverbrauch finden

   Beim Test wichtiger Pfade die Werte meta.rows_read und meta.rows_written jeder Abfrage auswerten. Abfrageanalysen helfen, häufige oder teure Anweisungen zu sortieren. Für die teuerste Leseabfrage EXPLAIN QUERY PLAN ausführen und einen vollständigen Scan beheben, bevor ein Tarifwechsel als einzige Lösung gilt.

3. 3

   Vor der harten Grenze alarmieren

   Die GraphQL Analytics API greift auf dieselben Datensätze wie das Dashboard zu und eignet sich für eine geplante Kontoprüfung. Bei 4 Millionen Lese- oder 80,000 Schreibvorgängen sollte die verantwortliche Person alarmiert werden. Cloudflares E-Mail am vollständigen Limit bleibt als Bestätigung des Vorfalls hilfreich, darf aber nicht das erste Produktionssignal sein.

4. 4

   Das Verhalten im Fehlerfall vorab festlegen

   Vorab definieren, was der Worker zurückgibt, wenn D1 einen Limitfehler auslöst. Eine zwischengespeicherte Leseantwort kann weiterhin nützlich sein, sofern sie keine weitere D1-Abfrage ausführt. Ein Schreibpfad benötigt eine eindeutige Antwort, dass der Dienst nicht verfügbar ist, oder eine separat konzipierte Warteschlange. Wiederholungsschleifen sind bei einem Kontingent sinnlos, das sich erst um Mitternacht UTC oder durch ein Upgrade erholt.

Die Dokumentation zu D1-Kennzahlen bezeichnet rowsRead und rowsWritten als GraphQL-Felder und bestätigt, dass das Dashboard dieselben Analysedaten nutzt. Damit steht einem kleinen Team heute ein manueller Weg zur Verfügung – und später ein automatisierbarer, sobald die Datenbank wichtig genug ist, um jemanden zu alarmieren.

Was die Lösung tatsächlich nicht leistet

Ein Index ist nicht kostenlos. Er benötigt Speicher und verursacht Schreibvorgänge, wenn sich indexierte Werte ändern. Sinnvoll sind die Indizes, die teure Scans beseitigen; danach wird das neue Verhältnis gemessen. Ein Konto, das bereits nahe am Limit von 100,000 Schreibvorgängen liegt, kann mit wahllosem Indexieren den falschen Tausch eingehen.

Auch Paid ist nicht unbegrenzt. Enthalten sind monatlich 25 Milliarden Lese- und 50 Millionen Schreibvorgänge; darüber hinaus wird Mehrverbrauch zu den veröffentlichten Preisen berechnet. Ein Upgrade hebt den täglichen Stopp von Free typischerweise innerhalb weniger Minuten auf. Es ersetzt jedoch weder die Überwachung schlechter Abfragen noch die Prognose für die übrige Workers-Rechnung. Cloudflares aktuelle D1-Preisseite gehört als Zahlenquelle in das Betriebshandbuch.

Eine Besonderheit der Quellenhistorie sollte bekannt sein. In einer D1-Versionsnotiz vom Januar 2025 stand, die Durchsetzung beginne am 10. Februar 2025. Das neuere, auf das konkrete Ereignis bezogene Changelog nennt dagegen den 1. September 2026. Hier gilt die neuere Seite als maßgeblich, weil sie den aktuellen Rollout ausdrücklich benennt. Deshalb kann ein älteres Suchergebnis ein anderes Datum anzeigen.

Und schließlich ist „gespeicherte Daten sind nicht betroffen“ eine engere Aussage als „mit dem Produkt ist alles in Ordnung“. Die Daten können sicher sein, während jeder darauf angewiesene Pfad einen Fehler zurückgibt. Die geschäftliche Folge ist mangelnde Verfügbarkeit.

Was am Montag zu tun ist

Noch diese Woche besteht Handlungsbedarf, wenn eine kundennahe Anwendung auf Workers Free läuft und D1 im Anfragepfad liegt. Zuerst messen, offensichtliche Scans beheben, den Alarm bei 4 Millionen Lese- und 80,000 Schreibvorgängen setzen und den Wechsel zu Paid für $5 vorab genehmigen.

Abwarten ist vertretbar, wenn es sich um einen entbehrlichen Prototyp handelt, der Verlauf der letzten 31 Tage deutlich unter dem Betriebsbudget bleibt und ein Tag mit fehlgeschlagenen Abfragen weder Kunden noch Umsatz beeinträchtigen würde. Der Alarm bleibt dennoch sinnvoll, denn sowohl der Datenverkehr als auch die Tabellengröße verändern die Leserechnung.

Von diesem konkreten täglichen Stopp nicht betroffen sind Konten, die bereits Workers Paid nutzen, sowie Anwendungen, die D1 nicht abfragen.

Der nächste Montagsschritt ist einfach: Für jede Datenbank die Registerkarte D1 Metrics öffnen, den Tag mit den höchsten Lese- und Schreibwerten des Kontos notieren, die für den größten Scan verantwortliche Abfrage bestimmen und genau einer Person die Befugnis zum Upgrade geben. Überschreitet eine normale Spitze nach der Abfrageoptimierung weiterhin 4 Millionen Lese- oder 80,000 Schreibvorgänge, sollte das Konto noch am selben Tag zu Workers Paid wechseln.

Wenn die nächste Plattformänderung wieder in eine konkrete Betriebsentscheidung übersetzt werden soll, hilft der Newsletter weiter.