Ein Produkt auf Cloudflare Edge betreiben: Was wir gewonnen, was wir aufgegeben haben

Jede D1-Datenbank, die wir betreiben, hat dieselbe Obergrenze: 10 GB, hart, pro Datenbank — eine Zahl, die Cloudflares eigene Dokumentation klar benennt und die sich weder 2025 noch 2026 bewegt hat (opens in new tab). Wir haben sie einmal in einem Test-Harness gerissen, das eine Woche lang jeden HTTP-Request-Body mitgeschrieben hat. Der Write scheiterte mit einem lakonischen SQLITE_FULL. Das ist der Deal, den Sie unterschreiben, wenn Sie auf Cloudflares Data Plane bauen — und unterm Strich halten wir ihn für gut. Dieser Beitrag ist der ehrliche Rundgang durch den Betrieb des Teknora-Stacks auf Workers + Pages + D1 + Workers AI — und wann wir Kunden sagen, sie sollen lieber Postgres auf Hetzner fahren.

Wir betreiben die Marketing-Site, den Blog, das Analytics-Dashboard und den Chatbot für teknora.org vollständig auf Cloudflare. Drei D1-Datenbanken binden in den Worker ein, plus Workers AI für die Chat-Inferenz und R2 für Bild-Assets. Das Ganze ist in rund vierzig Sekunden von git push bis zur global gecachten Antwort in Frankfurt deployt.

Der Stack, und warum

Next.js 15 App Router, kompiliert über @opennextjs/cloudflare (opens in new tab), deployt auf Workers mit einem Pages-artigen Asset-Binding. Die Persistenz übernehmen drei D1-Datenbanken via Drizzle ORM. Der Chatbot ruft Workers AI direkt über das Binding auf. Alles ist in wrangler.toml verdrahtet.

Zwei Punkte haben uns über die Default-Antwort „Vercel plus Neon" hinaus hierher getrieben. Erstens die Latenz in Deutschland: Die mediane TTFB aus München fiel von rund 180 ms auf Vercel auf rund 60 ms auf Workers, unterstützt von Cloudflares „Shard and Conquer"-Routing, das die Warm-Request-Rate auf 99,99 % gehoben hat (opens in new tab). Zweitens die Kosten: Der Workers-Paid-Plan beginnt bei 5 USD/Monat mit 10 Mio. Requests, Workers AI läuft im selben Abrechnungsrahmen zu 0,011 USD pro 1.000 Neurons mit 10.000 Neurons pro Tag gratis (opens in new tab), und Egress ist null.

Was wunderbar funktioniert

Preview-Environments sind kostenlos und sofort verfügbar. Jeder Branch bekommt eine Preview-URL mit eigenem D1-Binding (preview_database_id) und eigenem KV. Stakeholder klicken einen Link vom Handy aus an; er rendert in 40 ms aus London.

Deployments sind schnell genug, um langweilig zu sein. Ein vollständiger Production-Build mit MDX-Pipeline und Chatbot-Knowledge-Base-Prebuild dauert rund 40 Sekunden. Rollbacks über das Dashboard sind praktisch verzögerungsfrei.

Das Binding-Modell ist still exzellent. Statt DATABASE_URL-Strings bekommen Sie typisierte Bindings: env.TRACKING_DB, env.AI. Keine Credentials im Code, kein Connection-Management. Das Workers-AI-Binding ist angenehm: await env.AI.run("@cf/meta/llama-3.2-3b-instruct", { messages }) mit pro-Modell-Token-Pricing (opens in new tab), das bei kleinen Modellgrößen oft eine Größenordnung günstiger ist als OpenAI.

Kosten auf KMU-Skalierung sind ein Rundungsfehler. Für Mittelstands-Workloads — ein paar hunderttausend Requests am Tag, wenige GB Daten, ein Chatbot, der hundert Gespräche abwickelt — ist die Rechnung im Rauschen.

Was wirklich schwer ist

D1 ist unter der Haube SQLite — wunderschön einfach für Reads, schmerzhaft für konkurrierende Writes.

D1 ist Single-Writer, und Sie werden es spüren. Ein Worker kann bis zu 6 gleichzeitige Verbindungen öffnen (opens in new tab), aber die Datenbank serialisiert Writes. Globale Read-Replication via Sessions API hat im April 2025 die Public Beta erreicht (opens in new tab) und hilft spürbar. Für Write-Fanout-Workloads — Analytics bei jedem Pageview, Bulk-Upsert-Consumer — laufen Sie schnell in Contention. Unser Workaround auf TRACKING_DB war, Writes hinter einer Queue zu batchen. Das funktioniert, ist aber kein Muster, das Sie auf Postgres bräuchten.

Die 10 GB-Grenze ist real, und Sharding ist Ihre Aufgabe. Sie können bis zu 50.000 Datenbanken pro Account auf dem Paid-Plan (opens in new tab) provisionieren und pro Mandant shardten; öffentliche Writeups dokumentieren den Weg von 10 GB zu mehreren hundert GB via manuellem Sharding (opens in new tab). Aber „manuelles Sharding" heißt: Sie schreiben die Routing-Schicht, Cross-Shard-Queries und Migrationen selbst — eine reale Fehlerquelle, insbesondere für Reports, die alle Mandanten gleichzeitig sehen wollen.

Schema-Migrationen sind brauchbar, nicht großartig. wrangler d1 migrations apply wendet geordnete SQL idempotent mit einer Tracking-Tabelle an und rollt bei Fehlern auf den zuletzt erfolgreichen Stand zurück (opens in new tab). Was im Vergleich zum Postgres-Tooling fehlt: kein EXPLAIN für die Migration, keine Online-DDL, keine bequeme Art, dieselbe Migration über Dutzende mandanten-gesharder Datenbanken auszurollen, ohne das selbst zu skripten. Die Drizzle-Community löst den letzten Teil mit eigenen Skripten (opens in new tab), und der Wrangler-Feature-Request für Multi-Database-Apply (opens in new tab) ist weiterhin offen.

N+1 ist im Edge-Kontext schlimmer, als Sie es in Erinnerung haben. Jede Query ist ein eigener Hop durch die Worker-Runtime zur Datenbank-Shard. Wir haben eigene N+1s gefunden, die eine Seite von 80 ms auf 600 ms gezogen haben. Batchen oder IN (...), alles; behandeln Sie Promise.all über das D1-Binding als Geruch.

Die Next.js-auf-Cloudflare-Geschichte

Früher ein Trümmerfeld, jetzt tatsächlich in Ordnung. @cloudflare/next-on-pages war der ursprüngliche Adapter und hat einen großen Teil der Feature-Oberfläche verschluckt. 2024 ist Cloudflare auf @opennextjs/cloudflare (opens in new tab) umgeschwenkt, der die Node-Runtime von Next.js innerhalb eines Workers ausführt; er ist 2025 auf 1.0 gegangen und ist heute der empfohlene Weg (opens in new tab).

Was Sie heute bekommen: App Router, Route Handlers, dynamische Routes, SSG, SSR, ISR, Standard-Middleware, Image Optimization, Partial Prerendering, after(), Composable Caching, Turbopack-Assets. Was Sie Stand April 2026 nicht bekommen: Node Middleware aus 15.2 wird noch nicht unterstützt (opens in new tab), die Edge-Runtime von Next.js ebenfalls nicht, und die Worker-Größenobergrenze liegt bei 3 MiB komprimiert auf Free, 10 MiB auf Paid (opens in new tab). Ein spezifischer Biss: next-mdx-remote erzeugte eine Bundle-Form, die das RSC-Prerender nicht serialisieren konnte; wir sind auf next-mdx-remote-client migriert. Ein halber Tag Yak-Shaving — die Sorte Kröte, die Sie schlucken, wenn Sie den Adapter fahren statt die native Vercel-Integration.

EU-Datenresidenz in der Praxis

Genau hier ist Cloudflare 2025 für DACH-Mittelstandskunden von „vielleicht" zu „benutzbar" geworden. Seit November 2025 unterstützt D1 Jurisdiktions-Pinning zum Zeitpunkt der Datenbankerstellung (opens in new tab) mit eu und fedramp. Sie legen mit npx wrangler d1 create db-name --jurisdiction=eu an, und die Datenbank — einschließlich etwaiger Read Replicas, beschränkt auf dieselbe Jurisdiktion (opens in new tab) — läuft ausschließlich innerhalb der EU. Die Jurisdiktion ist unveränderlich.

Zwei Einschränkungen für einen Prüfer. Der Worker, der eine gepinnte Datenbank abfragt, kann weiterhin global irgendwo laufen — die Jurisdiktion begrenzt, wo die Daten leben, nicht die Compute. Halten Sie einen Satz dazu für die DSFA bereit. Und R2 hat seine eigene Jurisdiktions-Story (EU funktioniert), KV bietet noch kein hartes Pinning, und die Ausführung von Workers AI ist modellabhängig. Für strikte Residenz — Gesundheitsdaten, juristische Akten — lesen Sie die Data-Localization-Suite (opens in new tab) und budgetieren Sie für Enterprise. Für eine Marketing-Site, ein Chatbot-Log und einen Kampagnen-Tracker reichen die Defaults.

Wann wir Kunden zum Wechsel raten

Schweres OLTP mit Write-Contention. Tausende Writes pro Sekunde gegen einen einzelnen logischen Datensatz mit starker Konsistenz? Postgres auf Hetzner mit einer Read-Replica oder Neon (opens in new tab) für serverless-artige Ergonomie tut weniger weh. D1s Single-Writer ist für die meiste SaaS in Ordnung; nicht für ein POS-Backend, das Warenbestand gegen nebenläufige Kassen bucht.

Long-running Jobs. Workers Paid läuft inzwischen bis zu 5 Minuten CPU pro Request und 15 Minuten auf Cron Triggers oder Queue Consumers (opens in new tab), ein großer Sprung gegenüber dem alten 30-Sekunden-Default. Was es nicht deckt: ein nächtliches ETL, das 50 Mio. Zeilen umstapelt, ein Video-Transcode, eine 2.000-seitige PDF-Pipeline. Dafür betreiben wir Hetzner mit Coolify — eine reale Linie in der SMB-Cloud-Ökonomie (opens in new tab) zu 5–10 €/Monat.

Postgres-spezifische Features, die wir tatsächlich nutzen. Row Level Security, LISTEN/NOTIFY, Partial Indexes, jsonb mit GIN, logische Replikation, PL/pgSQL-Trigger. Das auf D1 zu emulieren übersteigt den Edge-Nutzen. Wir haben aus genau diesem Grund ein kleines Projekt von D1 heruntermigriert.

Reporting und analytische Queries. D1 ist OLTP-SQLite, kein Warehouse. Das 30-Sekunden-Query-Limit und die Row-Scan-Kosten bedeuten, dass ein Pivot über alle Accounts in den Timeout läuft. Dafür synchronisieren wir in ClickHouse (opens in new tab), DuckDB auf Object Storage oder Cloudflares Analytics Engine.

Eine kurze Entscheidungs-Checkliste

Wir nutzen beim Scoping von Kundenprojekten eine einseitige Checkliste:

• Bleibt der Datensatz pro Mandant voraussichtlich fünf Jahre lang unter 10 GB? Wenn nein, planen Sie Sharding ab Tag eins oder nehmen Sie Postgres.
• Sind Writes bursty-und-nebenläufig? Setzen Sie eine Queue davor.
• Brauchen Sie eine Reporting-Schicht über den operativen Daten? Planen Sie den Sync-Pfad, bevor Sie den Primärspeicher wählen.
• Steht Datenresidenz im Vertrag? EU-Jurisdiktion auf D1 deckt vieles ab; Hetzner in Nürnberg deckt den Rest.
• Long-running Job im Domänenmodell? Lassen Sie ihn nicht vom Worker besitzen — Cron + Queue + ein Hetzner-Worker oder ein Workflow.
• Ist das Team bereits fit in Postgres? Langweilige Technik, die das Team um 2 Uhr morgens bedienen kann, schlägt clevere Technik, die es nicht kann.

Bei den letzten sechs Mittelstandsprojekten liefen vier wunderbar auf Cloudflare, eins lief auf Hetzner, weil der Workload ETL-förmig war, und eins lief hybrid — Edge-Web-Tier, Hetzner-managed Postgres hinter einem privaten Tunnel für den OLTP-Kern. Alle drei waren günstiger und schneller auszuliefern als die Reflexantwort „Vercel plus AWS RDS". Die Edge ist keine Wunderwaffe; sie ist eine spezifische architektonische Haltung, und das Wertvollste, das ein Senior Engineer einbringt, ist zu wissen, auf welcher Seite der Linie Sie stehen — bevor der Vertrag unterschrieben ist.

Weiterführende Literatur

• Cloudflare D1 Platform Limits (opens in new tab) — die maßgebliche Liste; überfliegen Sie sie vor jedem D1-basierten Design.
• Cloudflare Workers Platform Limits (opens in new tab) — CPU-Zeit-Stufen, Subrequest-Zähler, Speicher.
• D1 Read Replication Deep-Dive (opens in new tab) — wie die Sessions API über Replicas hinweg sequenzielle Konsistenz hält.
• @opennextjs/cloudflare-Dokumentation (opens in new tab) — unterstützte Next.js-Features und bekannte Einschränkungen.
• D1-Jurisdictions-Changelog (Nov. 2025) (opens in new tab) — EU- und FedRAMP-Daten-Pinning.
• „Shard and Conquer"-Cold-Start-Beitrag (opens in new tab) — die Story zur 99,99 %-Warm-Rate.