Django vs FastAPI auf Cloudflare Workers: Der Praxisvergleich

Django vs FastAPI auf Cloudflare Workers: Welches Framework passt?

Django ist richtig, wenn bereits eine Django-Anwendung existiert oder ein vollständiges Produkt-Backend gefragt ist. FastAPI passt zu einer neuen typisierten API, einem Webhook-Dienst oder einem I/O-intensiven Edge-Endpunkt. Erfüllt ein benötigtes Paket, Prozessmodell oder zustandsbehafteter Workload die Anforderungen der Workers-Laufzeit nicht, sollte die Anwendung unabhängig vom Framework auf ihrem bisherigen Origin bleiben.

Cloudflare hat die Ausgangslage am 2. September 2026 verändert. Python Workers können WSGI- und ASGI-Anwendungen nun über Adapter im Modul workers direkt hosten. WSGI ist die klassische synchrone Schnittstelle für Python-Webanwendungen. ASGI ist ihr asynchroner Nachfolger und auf überlappende I/O-Vorgänge, Streaming und langlebige Verbindungen ausgelegt. In den Release-Beispielen von Cloudflare wird Django ausdrücklich mit WSGI und FastAPI mit ASGI kombiniert, auch wenn Django beide Protokolle unterstützt.

Django ist bei einer Migration die sicherere Wahl, wenn der integrierte Produktumfang bereits geschäftlichen Wert liefert. Cloudflare dokumentiert inzwischen WSGI- und ASGI-Einstiegspunkte sowie einen django-cf-Pfad für D1 und Durable Objects.

FastAPI ist auf der grünen Wiese die klarere Wahl, wenn eine API statt eines Webprodukts mit Admin-Oberfläche entstehen soll. Cloudflare stellt die ASGI-Serverschicht bereit; der Worker muss daher weder Uvicorn ausführen noch einen Socket verwalten.

Preislich herrscht Gleichstand – bis die CPU-Zeit abweicht

Beim Framework-Preis gibt es keinen Vorteil. Die Preise wurden am 5. September 2026 anhand aktueller Primärquellen geprüft: Django ist kostenlos und Open Source unter der BSD-Lizenz, FastAPI verwendet die MIT-Lizenz, und Workers Paid beginnt bei $5 pro Konto und Monat.

In diesen $5 sind 10 Millionen Requests und 30 Millionen CPU-Millisekunden pro Monat enthalten. Jede weitere Million Requests kostet $0.30, jede weitere Million CPU-Millisekunden $0.02. Requests für Static Assets sind kostenlos und unbegrenzt. Workers Free umfasst 100,000 Requests pro Tag, doch das CPU-Budget von 10 ms pro Aufruf eignet sich nicht als belastbare Vergleichsbasis für anspruchsvollere Framework-Anwendungen.

Werden beide Frameworks auf denselben Workload normiert, fällt das Ergebnis absichtlich unspektakulär aus. Bei 15 Millionen dynamischen Requests im Monat und durchschnittlich 7 ms CPU-Zeit pro Request kosten beide Frameworks $8 pro Monat: $5 Grundpreis, $1.50 für zusätzliche Requests und $1.50 für zusätzliche CPU-Zeit. Bei 100 Millionen Requests und denselben durchschnittlichen 7 ms sind es in beiden Fällen $45.40 pro Monat.

Aussagekräftiger als ein erfundener Framework-Benchmark ist die Sensitivitätsrechnung. Sobald beide Anwendungen das enthaltene CPU-Kontingent ausgeschöpft haben, verändert jede Abweichung von durchschnittlich 1 ms die Rechnung bei 15 Millionen Requests um $0.30 und bei 100 Millionen Requests um $2. Eine gemessene Differenz von 5 ms entspricht bei diesen Laststufen also $1.50 beziehungsweise $10 pro Monat. Das reicht bei Weitem nicht aus, um allein wegen der Rechenkosten einen Framework-Wechsel zu rechtfertigen.

Einen preislichen Kipppunkt beim Anbieter gibt es nicht. Eine Option wird erst dann günstiger, wenn sich ihre gemessene CPU-Zeit, unterstützende Dienste oder der Wartungsaufwand unterscheiden. Ein schnelles Framework kann eine Architektur mit langsamen Datenbankaufrufen nicht retten. Umgekehrt kann ein integriertes Framework, das mehrere Wochen Ersatzarbeit vermeidet, trotz schlechterem Mikrobenchmark das günstigere Gesamtsystem sein.

Migration: Django für bestehende Systeme, FastAPI für neue APIs

Der Adapter ist schnell geändert, die Anwendung nicht. Beide Frameworks benötigen nur einen schlanken Einstiegspunkt. Alles dahinter muss jedoch weiterhin zum Paket-, Speicher-, Dateisystem- und Lebenszyklusmodell von Cloudflare passen.

Django zu Cloudflare Workers migrieren: Der Adapter ist der einfache Teil

Django kann sein übliches WSGI-Anwendungsobjekt behalten und an den Cloudflare-Adapter übergeben:

import os

from django.core.wsgi import get_wsgi_application
from workers import wsgi

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
app = get_wsgi_application()
Default = wsgi.entrypoint(app)

Damit wird ein eingehender Workers-Request an Djangos WSGI-Callable übergeben. Datenbank, persistente Dateien, geplante Jobs, Sitzungsstrategie und sämtliche Django-Pakete von Drittanbietern sind dadurch noch nicht migriert.

Der neue Django-Paketleitfaden von Cloudflare eröffnet dem Framework einen echten nativen Speicherpfad. Das Paket django-cf stellt SQLite-kompatible Backends für D1 und Durable Objects bereit. Beide bedienen Djangos synchrones ORM, weshalb Cloudflare für diese Konfiguration WSGI vorgibt. Bei einem CRUD-Produkt, das bereits Modelle, Formulare, Authentifizierung und Admin nutzt, spart der Erhalt dieser Schichten weit mehr Arbeit, als ein Framework-Wechsel bei den Laufzeitkosten je einsparen könnte.

Die Grenze ist erreicht, sobald das bestehende System einen klassischen Server voraussetzt. Ein Datenbanktreiber kann ein natives Wheel benötigen, das Workers nicht laden kann. Nutzer-Uploads können nicht im Dateisystem des Isolates verbleiben. Ein prozesslokaler Scheduler oder Thread-Pool lässt sich nicht übernehmen. Django-Unterstützung bedeutet, dass das Request-Protokoll funktioniert – nicht, dass damit die gesamte installierte Anwendung zertifiziert ist.

FastAPI zu Cloudflare Workers migrieren: Ideal für klar begrenzte Dienste

Der direkte Adapter von FastAPI ist kleiner, weil das Framework bereits ASGI spricht:

from fastapi import FastAPI
from workers import asgi

app = FastAPI()
Default = asgi.entrypoint(app)

Cloudflare übernimmt die ASGI-Serverrolle, die normalerweise Uvicorn ausfüllt. FastAPI behält Routendeklarationen, Pydantic-Validierung, Dependency Injection und die generierte OpenAPI-Dokumentation. Ein neuer Webhook-Empfänger, eine typisierte JSON-API oder ein Dienst auf Basis von Bindings startet dadurch mit weniger Anwendungsballast als Django.

Der Preis dafür ist Integrationsarbeit. FastAPI schreibt weder Datenbank noch Datenmodell vor und bringt auch keine Content-Admin-Oberfläche wie Django mit. Diese Bausteine müssen ausgewählt, einzeln gegen die Workers-Umgebung geprüft und selbst integriert werden. Für einen fokussierten Dienst ist das ein Vorteil; für ein Produkt, dessen Betriebsteam vom ersten Tag an ein Backoffice benötigt, ist es zusätzlicher Aufwand.

Sieger bei der Migration: Django für eine Anwendung, die bereits auf Django basiert; FastAPI für eine neue API. Ein funktionierendes Django-System allein deshalb in FastAPI neu zu schreiben, weil beide nun an der Edge laufen, ist das falsche Projekt.

WSGI vs ASGI bei Cloudflare: FastAPI gewinnt bei Nebenläufigkeit, Django bleibt flexibel

Für einen neuen I/O-intensiven Dienst ist ASGI das stärkere Request-Modell. Für Djangos Cloudflare-ORM-Integration bleibt WSGI jedoch der dokumentierte Weg. Das Protokoll richtet sich nach dem Workload – nicht nach der pauschalen Behauptung, asynchron sei immer schneller.

WSGI stellt die Anwendung als synchrones Callable bereit. Der aktuelle WSGI-Adapter von Cloudflare führt dieses Callable innerhalb des asynchronen fetch-Handlers des Workers aus, überbrückt den Request-Body aus einem JavaScript-ReadableStream und streamt das Response-Iterable der Anwendung an den Client zurück. Das ist ein Kompatibilitätspfad für ausgereifte synchrone Anwendungen, kein zweiter Webserver im Isolate.

Mit ASGI kann die Anwendung Netzwerk- und Speicheroperationen abwarten, ohne den Request-Pfad durch einen synchronen Aufruf zu blockieren. Der Cloudflare-Adapter bildet außerdem ASGI-WebSocket-Ereignisse auf Workers WebSockets ab. FastAPI beruht auf diesem Modell. Django kann es ebenfalls nutzen; „Django“ und „WSGI“ sind daher keine Synonyme.

Die Speicherwahl kann die Protokollentscheidung umkehren. Laut Cloudflare greifen die D1- und Durable-Objects-Backends für Django beide auf das synchrone ORM zu und sollten über WSGI bereitgestellt werden. Wenn Djangos ORM der Grund für die Framework-Wahl ist, passt dieser dokumentierte WSGI-Pfad besser, als einer synchronen Datenschicht ein ASGI-Etikett aufzuzwingen.

Bei FastAPI hilft Async nur, wenn Arbeit tatsächlich parallel überlappt werden kann. Ein Endpunkt, dessen Zeit überwiegend in serieller Validierung oder CPU-intensivem Python vergeht, verbraucht weiterhin CPU-Zeit. Wartet er hingegen auf mehrere unabhängige HTTP- oder Cloudflare-Binding-Operationen, spricht deutlich mehr für ASGI.

Startverhalten: Die Überraschung beim FastAPI-Lifespan

Django über WSGI bietet auf Workers derzeit das berechenbarere Startmodell. FastAPI funktioniert weiterhin, doch seine Lifespan-Hooks verhalten sich nicht wie in einem langlebigen Uvicorn-Prozess.

Cloudflare reduziert die Kaltstartarbeit für Python mithilfe von Deployment-Snapshots. Bei der Bereitstellung erzeugt die Plattform ein V8-Isolate, bindet Pyodide ein, führt das Worker-Einstiegsmodul samt Top-Level-Imports aus und erstellt anschließend einen Snapshot des WebAssembly-Speichers. Für einen Request kann dieser Snapshot geladen werden, statt die Python-Umgebung von Grund auf neu aufzubauen. Code im globalen Gültigkeitsbereich muss dennoch innerhalb des plattformseitigen Startlimits von 1 Sekunde geparst und ausgeführt werden. Cloudflare dokumentiert diesen Lebenszyklus direkt.

Der normale Lifespan-Vertrag von FastAPI folgt einem Prozessmodell: Startcode läuft einmal, bevor die Anwendung Requests annimmt; der Shutdown-Code einmal, nachdem sie beendet wird. Der aktuelle Quellcode des Cloudflare-ASGI-Adapters verhält sich wesentlich anders. Seine fetch-Funktion startet die ASGI-Anwendung, sendet ein Lifespan-Startup-Ereignis, bearbeitet einen Request und sendet danach Shutdown. Der Kommentar im Quellcode beschreibt jeweils einen Start- und Stoppzyklus vor und nach dem Request.

Damit läuft Lifespan-Code beim aktuellen Adapter pro Request. Das Laden eines Modells, der Aufbau eines Verbindungspools, ein Schema-Warmup oder das Abrufen externer Konfiguration kann sich wiederholen, statt über die Lebensdauer eines Isolates amortisiert zu werden. Das spricht nicht grundsätzlich gegen FastAPI. Lifespan-Arbeit sollte aber günstig und idempotent sein; sichere deterministische Initialisierung gehört in Code, der vom Deployment-Snapshot von Cloudflare profitieren kann.

Die WSGI-Anwendung von Django wird im Cloudflare-Beispiel im Modul-Scope erstellt und besitzt keinen ASGI-Lifespan-Zyklus. Ihre Initialisierung gehört damit zum globalen Startpfad, dessen Grenze bei 1 Sekunde liegt. Wer Djangos ASGI-Einstiegspunkt und Lifespan-fähige Komponenten verwendet, muss sie unter demselben Adapterverhalten prüfen.

Cloudflare Workers Python: Beide Frameworks stoßen an dieselbe Paketgrenze

Hier herrscht Gleichstand – und beide Frameworks können ausscheiden. Django und FastAPI laufen in derselben Pyodide-Umgebung innerhalb von V8. Damit gelten für beide dieselben Grenzen bei Paketen, Speicher, Dateisystem und Startzeit.

Laut Paketdokumentation von Cloudflare bündelt pywrangler die in pyproject.toml deklarierten Abhängigkeiten. Unterstützt werden reine Python- und PyEmscripten-Pakete von PyPI sowie die mit Pyodide ausgelieferten Pakete. PyEmscripten bezeichnet das für WebAssembly kompilierte Wheel-Format. Cloudflare stuft dieses Ökosystem weiterhin als jung ein; für manche Pakete existiert kein kompatibles Wheel.

Die harten Plattformprüfungen sind eindeutig:

• Das unkomprimierte Worker-Bundle darf weder im Free- noch im Paid-Tarif größer als 64 MiB sein.
• Jedes Isolate verfügt über 128 MB Arbeitsspeicher.
• Der Start im globalen Gültigkeitsbereich muss innerhalb von 1 Sekunde abgeschlossen sein.
• Das Python-Dateisystem ist flüchtig und jeweils nur für ein Isolate zugänglich.
• threading und multiprocessing lassen sich importieren, funktionieren in der WebAssembly-VM aber nicht.

Das Dateisystem ist bei Migrationen häufiger ein Hindernis, als es die Adapter-Signatur vermuten lässt. Temporäre Dateien sind unproblematisch. Persistente Uploads, erzeugte Berichte, SQLite-Dateien als dauerhafter Zustand und gemeinsam genutzte Datenträger-Caches sind es nicht. Dauerhafte Objekte gehören je nach Zugriffsmuster in D1, Durable Objects, KV oder R2 – nicht in ein Verzeichnis, das mit dem Isolate verschwindet. Die genauen Grenzen stehen im Leitfaden zur Python-Standardbibliothek von Cloudflare.

Paketkompatibilität ist eine binäre Voraussetzung, bevor Performance überhaupt relevant wird. Zu prüfen ist der echte Abhängigkeitsgraph, nicht nur ein Hello-World-Ausschnitt. Ein erfolgreicher Import in CPython auf dem Desktop sagt nichts darüber aus, ob die nativen Erweiterungen in Pyodide verfügbar sind.

Betriebstauglichkeit: Django für Produkte, FastAPI für Dienste

Django liegt vorn, wenn die Arbeitseinheit ein Produkt ist; FastAPI, wenn sie ein Dienst ist. Diese Unterscheidung ist beständiger als der Framework-Durchsatz einer synthetischen Route.

Sieger bei Produkten mit Admin-Oberfläche: Django

Django bringt Benutzerauthentifizierung, Content-Administration, ein ORM, Templates, Middleware und weitere verbreitete Funktionen für Webprodukte mit. Die offizielle Übersicht nennt Authentifizierung und Content-Administration ausdrücklich. Muss ein kleines Betriebsteam Kunden, Bestellungen, Berechtigungen und redaktionelle Datensätze verwalten, kann die integrierte Admin-Oberfläche wertvoller sein als wenige eingesparte Millisekunden Framework-Overhead.

Auf Workers eröffnet django-cf diesem integrierten Modell einen Pfad zu D1 oder Durable Objects. Dafür entsteht eine stärkere Bindung an ein synchrones ORM, und der größere Framework-Umfang muss innerhalb der Laufzeitlimits bleiben.

Sieger bei typisierten API-Diensten: FastAPI

FastAPI ist auf OpenAPI, JSON Schema, Pydantic-Validierung und Dependency Injection ausgerichtet. Die Feature-Dokumentation macht auch die Kehrseite deutlich: Datenbank und Datenmodell bleiben frei wählbar. Das passt zu einem API-Gateway, Webhook-Empfänger, Modellendpunkt oder kleinen Dienst, der mit Bindings und externen APIs kommuniziert.

Fehlende integrierte Admin-Oberfläche und fehlendes ORM sind kein Nachteil, solange der Dienst sie nicht benötigt. Sobald nichttechnische Mitarbeitende ein Backoffice brauchen, werden sie zum Implementierungsaufwand.

Sieger bei Rohleistung: auf Workers nicht belegt

Die unabhängige TechEmpower-Suite führte FastAPI unter Uvicorn historisch unter den schnellsten Python-Frameworks, wie die Benchmark-Seite von FastAPI festhält. TechEmpower maß standardisierte JSON-, Datenbank-, ORM-, Template- und verwandte Workloads. Die Pyodide-Adapter von Cloudflare wurden nicht gemessen; zudem wurde das Projekt am 24. März 2026 eingestellt. Diese Ergebnisse sind ein zugeordneter historischer Hinweis, keine Prognose für ein Workers-Deployment.

Cloudflare hat für diese Adapter keinen Django-vs-FastAPI-Benchmark veröffentlicht. Die Rohleistung auf Workers bleibt deshalb unbelegt, bis eine repräsentative Route Validierung, Bindings, Datenbankaufrufe, Antwortformat, Startverhalten und Workers-CPU-Metriken einbezieht.

Was ein Wechsel wirklich kostet – und wer nicht wechseln sollte

Ein Framework-Wechsel allein für Cloudflare-Unterstützung lohnt sich nicht. Beide Frameworks bieten sie inzwischen. Ein Wechsel ist nur sinnvoll, wenn das Zielframework mehr Anwendungsarbeit beseitigt, als die Migration neu erzeugt.

Bei einer Neuentwicklung von Django zu FastAPI müssen Modelle, Migrationen, Admin-Oberflächen, Authentifizierungsabläufe, Middleware, Templates und alle Pakete ersetzt oder abgetrennt werden, die Djangos Request-Lebenszyklus voraussetzen. Für eine schlanke API kann das Ergebnis hervorragend sein, doch es handelt sich nicht um eine Deployment-Einstellung. Werden Admin und ORM intensiv genutzt, vernichtet der Wechsel zuerst Produktivitätsvorteile, bevor neue entstehen.

Ein Umstieg von FastAPI auf Django ergibt nur dann Sinn, wenn das Produkt aus einer dienstorientierten Architektur herausgewachsen ist und Djangos integrierte Betriebsoberfläche benötigt. Andernfalls kommen Konventionen und Komponenten hinzu, die eine kleine API nicht braucht.

FastAPI kann eine Django-WSGI-Anwendung über a2wsgi.WSGIMiddleware unter einem Pfad einbinden. Auf klassischen Servern kann das eine schrittweise Zerlegung ermöglichen. Auf Workers entstehen dadurch ein weiteres Paket und eine zusätzliche Protokollgrenze, während die Cloudflare-Einstiegspfade beide Frameworks separat dokumentieren. Ein kombinierter Worker ist daher eine individuell zu prüfende Integration, keine Standardabkürzung.

Bei jedem Wechsel müssen diese Migrationsbereiche kalkuliert werden:

• Daten: Schemakompatibilität, Migrationen, Transaktionsverhalten und der Umzug zu D1, Durable Objects oder einem anderen erreichbaren Speicher.
• Dateien: Statische Assets können Workers Static Assets nutzen; persistente Nutzermedien benötigen dauerhaften Objektspeicher wie R2.
• Hintergrundarbeit: Prozesslokale Scheduler, Thread-Pools und Kindprozesse müssen durch plattformnative asynchrone Arbeit ersetzt werden.
• Abhängigkeiten: Das vollständige Lockfile muss gegen Python Workers aufgelöst werden; anschließend sind das 64-MiB-Bundle und das Ergebnis beim 1-Sekunden-Start zu prüfen.
• Betrieb: Logs, Fehleralarme, Deployment-Rollback, Secrets und eine Performance-Baseline pro Route müssen neu aufgebaut werden.

Wer sollte nicht wechseln? Ein stabiler Django-Monolith mit funktionierender Datenbank und umfangreichen Admin-Abläufen sollte nicht aus Modegründen zu FastAPI werden. Ein FastAPI-Dienst, der von nicht verfügbaren nativen Wheels abhängt, sollte nicht allein deshalb auf Workers wechseln, weil das Framework nun eine Dokumentationsseite besitzt. Und ein Team, dessen Latenz von einer weit entfernten Datenbank bestimmt wird, sollte zuerst die Datenplatzierung korrigieren und erst danach das Request-Framework infrage stellen.

Der konkrete Schritt für Montag

In der kommenden Woche sollte eine repräsentative Route erprobt werden – nicht die gesamte Anwendung. Die Route sollte Paket-, Zustands- und Latenzeigenschaften des Produktionssystems abbilden und ungeeignete Optionen schnell sichtbar machen.

FastAPI vs Django: Häufige Fragen zu Cloudflare Workers