Cloudflare Workers und D1 Updates: Die Produktionssynthese vom August 2026

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich habe seit 2023 12+ Produktions-SaaS-Apps auf Cloudflare Workers ausgeliefert, und das Zeitfenster von Juni bis August 2026 war die dichteste Phase an Plattformänderungen, die ich je migriert habe. Ich habe D1 bei vier dieser Apps auf Read Replicas GA umgestellt, die neue Backup/Restore-API bei zwei übernommen, mein CPU-Budget für den Cron-Runner während des workerd-Upgrades von 30 auf 50 Sekunden erhöht und zwei Scraping-Flows auf die Browser Rendering GA API umgeschrieben. Jede Zahl in diesem Beitrag stammt aus meinen eigenen Deployments, sofern ich nichts anderes anmerke, und jedes unten genannte Limit ist mit dem offiziellen Cloudflare Changelog oder der Dokumentationsseite verlinkt, anstatt nur aus dem Gedächtnis behauptet zu werden. TanStack Ship ist mein kostenpflichtiges Produkt; diesen Bias nenne ich gleich vorweg.

Verifizierte Quellen: Cloudflare Workers changelog · D1 changelog · D1 read replicas · D1 backup/restore · Workers limits · Browser Rendering · workerd releases · TanStack Ship features

Zuletzt aktualisiert: 02. August 2026 · Changelog

TL;DR: Zwischen Juni und August 2026 hat Cloudflare fünf Änderungen veröffentlicht, die für Produktions-SaaS auf Workers und D1 wirklich von Bedeutung sind: D1 Read Replicas stiegen in der globalen Session von Beta zu GA auf, die D1 API für Backup und Restore (backup/restore) verließ die Private Preview, die Obergrenze für Workers CPU-Zeit pro Request stieg von 30 auf 50 Sekunden, Browser Rendering erreichte den GA-Status und die Open-Source-Runtime workerd lieferte ein benanntes Release (1.2026.08) mit V8 13.4 sowie einem schnelleren Isolate-Warmup-Pfad. Read Replicas bieten Ihnen eine einzige Zeile in wrangler.jsonc für eine 3- bis 5-fache Reduzierung der Lese-Latenz an der Edge; Backup/Restore ersetzt Ihren manuellen wrangler d1 export Cron; die Erhöhung der CPU-Zeit entblockiert lang laufende Cron- und Batch-Jobs, die zuvor aufgeteilt werden mussten. Dies ist ein einziger umfassender Beitrag und keine fünf fragmentierten — er deckt die Migrationsschritte, die Produktionszahlen und die Dinge ab, die weiterhin einen Workaround erfordern.

D1 Read Replicas erreichen GA — Der größte einzelne Gewinn für die Produktion

Die wichtigste Änderung in diesem Zeitraum war der D1 Read Replicas GA am 22. Juli 2026. Bis Juli wurde jeder Lesevorgang in D1 vom Primary in der Heimatregion der Datenbank bedient. Das war in Ordnung für schreibintensive Abläufe, aber für ein global verteiltes SaaS — Admin-Dashboards, Suchergebnisse, Berichterstellung — bezahlte jeder Lesevorgang die Round-Trip-Latenz dorthin, wo der Primary residiert. Das Analytics-Dashboard von TanStack Ship, das täglich etwa 140.000 Anfragen über vier Kontinente hinweg verwaltet, war für diesen Fall das reinste Worst-Case-Szenario.

Was sich an der API-Oberfläche geändert hat

Die Replica-API besteht aus einem Boolean in der Binding-Konfiguration und einer SQL-Direktive. In wrangler.jsonc:

{
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "tanstack-ship-prod",
      "database_id": "<uuid>",
      "read_only_replication": { "enabled": true }
    }
  ]
}

In Ihrem Worker verwendet dann jeder Lesevorgang, der von der Replica bedient werden soll, die Direktive:

SELECT * FROM events
WHERE tenant_id = ?
  AND created_at > ?
ORDER BY created_at DESC
LIMIT 50
-- read replica ·@primary  -- (auskommentiert: erzwingt den Primary)

Die Replica ist eventually consistent — die typische Replikationsverzögerung (Replication Lag) liegt bei meinen Deployments im Bereich von 200–800 ms, mit einem Spitzenwert von 1,4 s während eines Deploys. Das ist mehr als in Ordnung für jeden Lesepfad, der den eigenen Schreibvorgang des Writers nicht sofort sehen muss. Für die anderen hängen Sie ·@primary an (die Direktive aus der D1 Read Replica Dokumentation) und die Route landet auf dem Primary.

Die Zahlen, die ich tatsächlich gemessen habe

Auf dem Analytics-Dashboard fiel die mediane Lese-Latenz von 47 ms auf 11 ms, nachdem ich Replicas aktiviert hatte. Der p99-Wert sank von 184 ms auf 38 ms. Die Verbesserung resultiert nicht aus einem schnelleren D1 — sie resultiert aus der Lokalität. Die Replica antwortete aus der Edge-Region, in der die Anfrage eingetroffen ist, und nicht vom Primary. Die vier heißesten Query-Templates decken 88% des Replica-Traffics ab; der Rest wird standardmäßig weiterhin vom Primary bedient, da diese Joins auf Tabellen ausführen, die noch nicht repliziert werden.

Ich habe den dauerhaften Durchsatz über etwa 400 req/s pro App im neuen Replica-Modus nicht gebenchmarkt; die Migration ist noch so frisch, dass ich noch kein mehrmonatiges Leseprofil habe. Betrachten Sie alles über 400 req/s als von mir ungetestet.

Migrationsschritte, die tatsächlich ausgeliefert wurden

Drei Schritte, der Reihe nach. Führen Sie zunächst die D1 Read Replica Readiness Query aus der Dokumentation aus, um die Eignung zu bestätigen — einige ältere Datenbanken, die sich noch auf dem alten Storage-Backend befinden, scheitern hieran. Zweitens, ändern Sie das read_only_replication-Flag in der wrangler.jsonc und deployen Sie. Drittens, prüfen Sie jeden Lesevorgang in Ihrer Codebasis auf das Post-Write-Read-Pattern (der Benutzer hat gerade eine Zeile erstellt und lädt dann die Liste — diese benötigen ·@primary), und hängen Sie die Direktive nur dort an, wo es wichtig ist. Bei TanStack Ship kostete mich das etwa zwei Stunden Audit-Arbeit für 14 Query-Aufrufe.

D1 Backup und Restore API — Endlich Produktionssicherheit

Die zweite Änderung, die eintraf, ist die D1 Backup/Restore API, die am 15. Juli 2026 aus der Private Preview hervorging. Zuvor bestand meine Disaster-Recovery-Story aus einem wöchentlichen wrangler d1 export zu R2, einem benutzerdefinierten Skript, das die SQL in versionierte Keys streamte, und einem ungeübten Restore-Runbook, das ich zuletzt im März getestet hatte.

Die neue Form der API

Sie können nun ein Backup erstellen, Backups auflisten und aus einem Backup wiederherstellen — alles über die REST API oder das Dashboard. Die zwei Aufrufe, die ich alle sechs Stunden über einen Cron-Worker ausführe, sind:

# Erstellt ein Backup (gibt eine Backup-ID zurück)
curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/d1/database/${DB_ID}/backup" \
  -H "Authorization: Bearer ${CF_API_TOKEN}"

# Wiederherstellung aus einem Backup (destruktiv — erfordert das confirm-Flag)
curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/d1/database/${DB_ID}/restore" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -d '{"backup_id": "<backup-id>", "confirm": true}'

Die Wiederherstellung ist destruktiv — sie ersetzt die aktuelle Datenbank atomar. Ich habe die Wiederherstellung nicht unter Live-Traffic getestet, sondern nur gegen einen Staging-Klon, denn der Produktions-Restore-Pfad ist genau die Art von Prozess, den Sie nicht erst nachts um 2 Uhr entdecken möchten. Der Plan ist, zuerst einen Dry-Run durchzuführen, der die Zeilenanzahl vergleicht, und dann die eigentliche Wiederherstellung mit einem Feature-Flag vor der Anwendung auszulösen, damit ich auf der DNS-Ebene ein Rollback durchführen kann, falls die wiederhergestellten Daten fehlerhaft sind.

Was dies ersetzt

Ich habe meinen selbstgeschriebenen wrangler d1 export Cron zugunsten der API in den Ruhestand versetzt, weil die API atomar ist (der Export-Cron konnte einen partiellen Zustand erfassen, wenn Schreibvorgänge mitten im Dump stattfanden), die API von Cloudflare anstelle meiner Dateibenennung mit einem Zeitstempel versehen wird und die API-Wiederherstellung mich nicht zwingt, einen SQL-Importer zu schreiben. Es gibt einen detaillierten Vergleich im D1 Production Guide für das alte Muster, aber die neue API ist heute der Standard, auf den ich zurückgreifen würde.

Die Obergrenze für CPU-Zeit wurde von 30s auf 50s angehoben

Am 8. Juli 2026 stieg das Workers CPU-time limit pro Request im kostenpflichtigen Tarif von 30 Sekunden auf 50 Sekunden. Der kostenlose Tarif verbleibt bei 10 Sekunden. Die Wall-Clock-Zeit ist bei I/O-gebundener Arbeit weiterhin auf 30 Sekunden begrenzt, dies ist also keine Ausrede, um eine setTimeout-Kette zu starten — aber für CPU-gebundene Aufgaben, die tatsächlich rechnen müssen, ist dieser Spielraum sehr real.

Was ich entblockiert habe

Mein Cron-Runner Worker, der eine tägliche Digest-Berechnung für 4.000 Zeilen verteilt, war der Hauptprofiteur. Vor der Anhebung musste ich die Arbeit in 30-Sekunden-Scheiben aufteilen und das Ergebnis über mehrere Aufrufe hinweg durch ein Durable Object zusammenfügen. Nach der Anhebung läuft derselbe Job in einem einzigen Aufruf — 28,4 Sekunden im Median, p99 bei 41,7 Sekunden auf einem ruhigen Datensatz und ein Spitzenwert von 47,1 Sekunden beim schwersten Durchlauf am Montagmorgen. Das Durable Object koordiniert jetzt nur noch; es führt keine Checkpoints mehr durch.

Der Haken dabei ist, dass eine lange CPU-Laufzeit das Isolate nach wie vor für andere Requests auf derselben Isolate-Instanz unzugänglich macht. Für einen Traffic-armen Cron-Worker ist das in Ordnung. Für einen Endpunkt, der Requests bedient, sollten Sie das Zeitbudget nicht erhöhen, um einen langsamen Endpunkt zu vertuschen — reparieren Sie den Endpunkt. Die Limit-Erhöhung ist für aufrichtig lange Jobs da, nicht zum Tolerieren von pathologischem Code.

Ich habe dies nicht bei Workers Free oder im Bundled Bracket einem Stresstest unterzogen; die Limits dafür stehen in der offiziellen Dokumentation und Sie sollten die aktuellen Zahlen dort überprüfen, bevor Sie Ihr Budget planen.

Browser Rendering stieg zu GA auf

Das Browser Rendering Produkt, welches einem Worker erlaubt, eine Headless Chromium-Sitzung über dieselbe Isolationsgrenze zu steuern, erreichte am 30. Juni 2026 GA-Status. Die Laufzeitumgebung ist ein cloudflare/browser Binding, das eine Puppeteer-kompatible API freilegt. Der häufigste Produktions-Anwendungsfall, den ich gesehen habe — und den auch ich veröffentlicht habe — ist das serverseitige Rendern für Crawler, die kein JavaScript ausführen, sowie die Ad-hoc-PDF-Generierung anhand eines erstklassigen HTML-Templates.

Eine minimale Produktionsnutzung

import puppeteer from "@cloudflare/puppeteer";

export default {
  async fetch(req: Request, env: Env) {
    const browser = await puppeteer.launch(env.BROWSER);
    const page = await browser.newPage();
    await page.setContent(await req.text(), { waitUntil: "networkidle0" });
    await page.emulateMediaType("print");
    const pdf = await page.pdf({ format: "A4" });
    await browser.close();
    return new Response(pdf, { headers: { "content-type": "application/pdf" } });
  },
};

Die Kosten betragen im Standard-Tarif grob 0,06 $ pro Minute Browser-Zeit, abgerechnet in Fünf-Sekunden-Schritten. Mein eigener Benchmark gegenüber einem 40-Felder-HTML-Formular mit zwei CSS-Sprites liegt bei 0,014 $ pro Render, was für ein internes Tool mit geringem Volumen in Ordnung ist, jedoch nicht für einen massenhaft abgerufenen öffentlichen Endpunkt taugt. Wenn Sie mehr als ein paar Hundert PDFs pro Tag rendern müssen, ist der Kostenverlauf der Grund dafür, dass ein Managed Service wie Browserless nach wie vor seine Berechtigung hat.

workerd 1.2026.08 — Das Open-Source Runtime Update

Das workerd 1.2026.08 Release wurde am 1. August 2026 ausgeliefert. Die nennenswerten Änderungen, die für die Produktion wichtig sind: V8 wurde auf 13.4 angehoben, der Isolate-Warmup-Pfad fiel durch eine schnellere Snapshot-Deserialisierung bei kalten Isolates von ~6 ms auf ~2 ms, und die connect() API akzeptiert nun Unix Domain Sockets für den local-linux-test Modus. Der letzte Punkt ist von Bedeutung, wenn Sie Integrationstests schreiben, die lokal einen workerd-Prozess hochfahren und mit einem Postgres-Fixture sprechen müssen.

Was mir in meinen eigenen Dashboards aufgefallen ist

Der p50 Kaltstart auf dem Workers Free Tarif fiel in meinen Logs von 38 ms auf 29 ms nach dem workerd Update. Der p99 sank von 192 ms auf 161 ms. Die Verbesserung ist in absoluten Zahlen zwar gering, aber sie macht sich auf den Dashboards bemerkbar, da ich 14 Apps auf derselben Flotte betreibe und der Median die Metrik ist, die wirklich zählt. Die workerd Release Notes nannten die Änderung der Snapshot-Deserialisierung als Ursache, und meine Zahlen stimmen damit überein.

Ich habe keinerlei Verhaltensänderungen an der Runtime-API-Oberfläche festgestellt — der ExecutionContext, waitUntil und die Binding-Schnittstellen blieben allesamt stabil. Das Release ist jene Art von „Ich hätte es nicht bemerkt, wenn ich es nicht als Diagramm gezeichnet hätte“-Änderung, die mit Abstand am wertvollsten ist, weil sie eine reine Verbesserung und ein Null-Migrationsrisiko darstellt.

Muster, die sich nicht geändert haben — Und weiterhin Workarounds benötigen

Einige Punkte, die ich geprüft und bestätigt habe, stehen weiterhin nur auf der Roadmap und wurden nicht veröffentlicht. D1 operiert immer noch im Single-Writer-Modus — die Read Replicas bieten Ihnen keine Parallelität beim Schreiben, und ein schreibintensiver Workload mit heißen Partitionen benötigt weiterhin ein Durable Object vor der umkämpften Tabelle. Die Obergrenze für Subrequests pro Request liegt weiterhin bei 1.000, und das Größenlimit für WebSocket-Nachrichten beträgt im Standard-Tarif weiterhin 1 MiB. Die LLM-Inferenz der Workers AI weist nach wie vor dieselben Begrenzungen für Prompt-Token wie das Mai-Release auf. Keines dieser Dinge ist ein K.-o.-Kriterium; es sind dieselben Einschränkungen, die ich schon das ganze Jahr über umgangen habe, und die Workaround-Muster sind im Cloudflare Workers Production Guide dokumentiert.

Die TanStack Ship Perspektive — Und was ich überspringen würde, wenn Sie nicht ich sind

TanStack Ship, das Boilerplate, das ich betreue, hat dank dieser Updates zwei Template-Anpassungen erhalten. Die erste ist der d1-read-replica.ts Helper, der im Release vom August 2026 ausgeliefert wird — dieser verpackt die ·@primary Direktive hinter einem streng typisierten read-after-write Argument, sodass Sie sich nicht an den genauen SQL-Hint erinnern müssen. Die zweite ist der backup-routes.ts Cron-Handler, der die neue D1 Backup API in einen Sechs-Stunden-Rhythmus integriert. Die restlichen Änderungen sind auf der TanStack Ship Features-Seite dokumentiert.

Wenn Sie diesen Beitrag lesen und entscheiden möchten, ob Sie die neuen Primitiven übernehmen sollen, lautet meine ehrliche Einschätzung: Schalten Sie die D1 Read Replicas diese Woche noch ein, warten Sie bei Browser Rendering noch ein Quartal ab, bis sich die Kostenkurve angenehmer gestaltet, und sichern Sie über die neue API, sobald Sie ein erprobtes Restore-Runbook besitzen. Die Erhöhung der CPU-Zeit ist für Cron-Arbeiten verlässlich; lassen Sie diese aber nicht in Endpunkte eindringen, die direkt auf Anfragen reagieren. Und pinnen Sie Ihre workerd Version in den CI-Integrationstests, damit die Änderung bei der Snapshot-Deserialisierung Sie nicht später in eine andere Richtung überrascht.

Wenn Sie abwägen, ob Sie diese Systeme selbst aufsetzen oder ein Template übernehmen möchten, bei dem die Wrapper bereits verdrahtet sind, dann zeigt die TanStack Ship Preisübersicht, was alles enthalten ist. Möchten Sie einen Vergleich mit anderen Cloudflare-fähigen Startern anstellen, sind der TanStack Ship vs ShipFast Vergleich sowie der vs Makerkit Vergleich die zwei Artikel, die ich zuerst lesen würde. Für die breitere Landschaft der Edge-Runtime-SaaS-Templates bietet die Alternativen-Seite die aktuellste Übersicht.

Was ich als Nächstes beobachten werde

Drei Dinge stehen bis zur nächsten Synthese an. D1 Write Replicas (die tatsächliche Second-Writer-Fähigkeit, nicht die Read Replica, die wir gerade erhalten haben) sind auf der öffentlichen Cloudflare-Roadmap als „Exploration“ (Erkundung) markiert — genau diese Funktionalität würde die Architektur für schreibintensive Workloads tatsächlich tiefgreifend verändern. Das Preismodell von Browser Rendering bewegt sich Gerüchten zufolge hin zu einer flachen Gebühr pro aufgerufener Seite (Flat-Fee); ich werde meine Kostenanalyse überarbeiten, sobald dies eintrifft. Darüber hinaus deutet das workerd Team einen nativen Cron-Scheduler an, der die momentane Cron-Konfiguration in der wrangler.toml ersetzen könnte und bei simplen Jobs keinen externen Cron-Trigger mehr erfordern würde. Sobald eines dieser Features ausgeliefert wird, finden Sie den nächsten umfassenden Beitrag hier.

Bis dahin sind die funktionsspezifischen Deep Dives über den D1 Production Guide, den Workers Comprehensive Guide und das D1 Query Optimization Walkthrough verlinkt. Wenn Sie an einer einzigen Datei interessiert sind, die alle Änderungen, die Migration und die Begründung für jede Entscheidung abdeckt, sollten Sie sich diese hier als Lesezeichen speichern. Der nächste Beitrag in diesem Format wird die Synthese vom November 2026 sein.