Django im Test: Lohnt es sich noch?

Django hat in den acht Monaten zwischen Dezember 2025 und August 2026 zwei Feature-Releases veröffentlicht und seinen gesamten Release-Rhythmus neu geschrieben.

Das traf auf ein Framework, dessen Ruf sich seit 2023 kaum verändert hat: das Python-Framework mit allem drin, produktiv, meinungsstark, rein synchron und gegenüber FastAPI im Rückstand. Das Etikett „nur synchron“ ist überholt, und die Geschichte der Beliebtheit ist komplizierter, als die Schlagzeilenzahlen vermuten lassen.

Hier also mein Fazit zur Frage, ob sich Django in 6.1 noch lohnt: ein Urteil mit Bewertung, die Projektformen, zu denen es passt, und die, für die FastAPI inzwischen die bessere Wahl ist.

Die Kurzfassung

Ja, mit Einschränkungen. Django 6.1 bleibt die stärkste Standardwahl, wenn Admin, Auth, Formulare und ORM den Großteil der Arbeit ausmachen, und der Async-Rückstand ist so weit geschrumpft, dass „nur synchron“ kein Ausschlussgrund mehr ist. Für eine einzelne API mit hoher Nebenläufigkeit und ohne Admin-Oberfläche ist es falsch. 4 von 5.

• Man kauft das Gesamtpaket. ORM, Migrationen, Session-Auth mit Berechtigungen, eine Formularschicht und ein generiertes Admin kommen zusammen und bereits integriert, nicht als fünf Bibliotheken plus die Nahtstellen dazwischen.
• Hintergrundjobs sind die schwache Achse. Das Tasks-Framework von Django 6.0 gibt Ihnen einen Decorator und einen Enqueue-Aufruf, aber keinen Worker. Celery oder Vergleichbares bleibt damit eine Entscheidung, die Sie selbst treffen.
• Async ist deutlich besser und erkennbar unfertig. Django unterstützt Async-Views und asynchrone ORM-Aufrufe, doch Transaktionen funktionieren im Async-Modus nicht. Unter WSGI können Async-Views weiterhin nebenläufige asynchrone I/O innerhalb eines Requests ausführen, aber die Vorteile eines vollständig asynchronen Request-Stacks bekommen Sie nicht: langlaufende Requests und hohe Verbindungsnebenläufigkeit erfordern ASGI.
• Die Planung über 2027 hinaus ist einfacher geworden. Ab Januar 2028 veröffentlicht Django ein Feature-Release pro Jahr, jedes mit drei Jahren Support, und das Label „LTS“ entfällt, weil jedes Release nun diese Zusage bekommt.
• Richtig für admin- und CRUD-lastige Produkte und für kleine Teams. Falsch für eine einzelne API mit hohem Durchsatz oder Streaming, ohne Admin- oder Formularfläche, wo FastAPI die natürlichere Wahl ist.

Wie dieser Test entstanden ist: Dies ist eine Bewertung von Django 6.1, aufgebaut auf den Release Notes und der Dokumentation des Projekts selbst, der Governance-Ankündigung der Django Software Foundation vom August 2026, den Entwicklerumfragen von JetBrains/PSF 2024 und Django 2025 sowie namentlich genannten Praktikern, die öffentlich über ihre eigene Produktionserfahrung schreiben. Ich habe für diesen Beitrag keinen mehrwöchigen Produktivtest gefahren, und es gibt hier keine Benchmarks: Es wurde nichts unter Last getestet. Django ist kostenlos und BSD-lizenziert, und ich habe keine Beziehung zum Projekt.

Was hat sich in Django seit 2025 wirklich geändert?

Django 6.0 erschien am 3. Dezember 2025 mit einem hauseigenen Tasks-Framework und weiteren Ergänzungen im Kern. Die asynchrone ORM-Schnittstelle ist älter: Django 4.1 führte 2022 asynchrone QuerySet-Operationen ein. Django 6.1 wurde am 5. August 2026 zur aktuellen stabilen Version. Dann kündigte das Projekt am 10. August 2026 ein Feature-Release pro Jahr an, ab Januar 2028, drei Jahre Support für jedes Release und das Ende des LTS-Labels.

Die Release Notes zu 6.1 bestätigen, dass 6.1 Python 3.12, 3.13 und 3.14 unterstützt, wobei der Mainstream-Support im April 2027 und der erweiterte Support im Dezember 2027 endet.

Die Versionsnummern ändern sich mit. Sie tragen das Jahr: Django 2028, dann Django 2029 (immerhin lässt sich „Welche Version fahrt ihr?“ leichter beantworten). Die drei Jahre teilen sich in ein Jahr regulärer Bugfixes und zwei Jahre Sicherheits- und Datenverlust-Fixes, also genau das, was LTS früher bedeutete, weshalb das Label wegfällt.

Das hinterlässt ein unbequemes Zeitfenster für ein Projekt, das heute startet. Django 5.2 ist die aktuelle LTS und wird bis April 2028 unterstützt. Django 6.1 ist die aktuelle stabile Version, doch ihr erweiterter Support endet im Dezember 2027, rund vier Monate bevor der Supportzeitraum von Django 5.2 im April 2028 ausläuft.

Also: Wer das längste Supportfenster will, startet auf 5.2. Wer das Tasks-Framework und die neuesten 6.x-Funktionen will, startet auf 6.1 und nimmt ein früheres Upgrade in Kauf. Falsch ist keins von beidem, und die unbequeme Wahl verschwindet, wenn Django 6.2 LTS im April 2027 erscheint.

Ich lese die Änderung des Rhythmus als gutes Zeichen. Projekte im Niedergang dehnen ihre Supportversprechen still und leise; sie strukturieren sie nicht öffentlich mit einem datierten Plan um. Dieses hier hat eine Zusage vereinfacht, die es ohnehin schon eingehalten hat.

Was Django immer noch besser kann als alles andere

Starten Sie ein Django-6.1-Projekt, und Sie haben funktionierende Session-Authentifizierung mit Berechtigungssystem, eine Formularschicht, die validiert und rendert, ein an Ihre Modelle gebundenes Migrationssystem, das ORM und ein generiertes Admin, bevor Sie ein einziges Feature schreiben. Das ist das ganze Versprechen, und es ist der Teil von Django, der sich nicht ändern musste.

Der Wert liegt nicht darin, dass es diese Teile gibt. Er liegt darin, dass sie aufeinander hin entworfen wurden. Dieselben Modellberechtigungen speisen das Admin, und eine Modelländerung erzeugt die Migration und aktualisiert das Admin-Formular im selben Zug.

Eine gleichwertige Abdeckung aus unabhängigen Bibliotheken zusammenzubauen bringt Sie irgendwann ans Ziel. Es bringt Ihnen außerdem eine dauerhafte Wartungsfläche an jeder Nahtstelle, und in den Nahtstellen wohnen die Bugs.

Das Admin ist ein Werkzeug für Mitarbeitende. Die Admin-Referenz sagt, ihre empfohlene Verwendung beschränke sich auf ein internes Verwaltungswerkzeug einer Organisation und sie sei nicht dafür gedacht, das gesamte Frontend darum herum zu bauen. Modellberechtigungen steuern, was Mitarbeitende drinnen tun dürfen, und um überhaupt hineinzukommen, braucht es is_staff. Nehmen Sie das als Einschränkung, und es ist eine gute: Sie bekommen kostenlos ein solides internes Backoffice und Sie bekommen keine kundenseitige Oberfläche, also ist niemand versucht, eine auszuliefern.

Die Sicherheits-Defaults sind die andere Hälfte desselben Arguments. CSRF-Schutz, SQL-Parametrisierung über das ORM, XSS-Escaping in Templates und Clickjacking-Schutz sind standardmäßig aktiv, statt Dinge zu sein, an die ein erfahrener Entwickler im Review erinnern muss. Ein kleines Team erbt Entscheidungen von Leuten, die ein Jahrzehnt Sicherheitsberichte gelesen haben.

Dann ist da noch das Alter. Es wird als Belastung gelesen; ich lese es als das Ökosystem-Argument. Django REST Framework existiert und ist langweilig auf genau die Art, wie man sich Infrastruktur langweilig wünscht.

Dasselbe gilt für ausgereifte Pakete zu den Problemen, auf die man im vierten Monat stößt: Filterung, Throttling, Storage-Backends, Mandantenfähigkeitsmuster, Audit-Trails. Und wenn ein Problem ungewöhnlich genug ist, dass es kein Paket abdeckt, gibt es dazu meist einen fünfzehn Jahre alten Mailinglisten-Thread. Bei der Breite kommt aus meiner Sicht nichts anderes in Python heran, und genau diese Achse ist der Grund, warum man Django überhaupt wählt.

Wo Django zu kurz greift

Django fehlt weiterhin eine umfassende hauseigene Typisierung über das ganze Framework, das konservative Tempo lässt Lücken, vor denen „alles inklusive“ nicht warnt, und dem Tasks-Framework aus 6.0 fehlt der Worker. Das sind die drei Defizite bei 6.1. Die Typisierungslücke ist die, die täglich nervt; Tasks ist die, die Ihr Architekturdiagramm verändert.

Den Großteil der Typisierung bauen Sie sich weiterhin aus Drittanbieter-Werkzeugen zusammen. django-stubs liefert Type-Stubs plus ein eigenes mypy-Plugin für Djangos dynamisches Verhalten. Die aktuelle Dokumentation nennt volle mypy-Unterstützung sowie Basisunterstützung für pyright, pyrefly und ty. Das ist besser als früher, bleibt aber eine separate Kompatibilitätsschicht statt einer umfassenden hauseigenen Typisierung in Django selbst.

Wer von einem Framework kommt, das um Type Hints herum gebaut ist, erlebt hier einen messbaren Rückschritt in der täglichen Editor-Erfahrung.

Das konservative Tempo ist ebenso Kosten wie Tugend. Django fügt Dinge sorgfältig und spät hinzu, und deshalb ist das Framework, das Sie 2019 gelernt haben, dasselbe, das Sie heute lesen können. Deshalb enden die Batterien auch dort, wo sie enden: keine WebSocket-Schicht im Kern, kein Scheduler, keine Meinung zur Orchestrierung asynchroner Aufgaben. Überschreiten Sie eine dieser Linien, bauen Sie wieder selbst zusammen.

Braucht Django 6 noch Celery?

Nicht speziell Celery. Djangos Tasks-Framework in 6.0 standardisiert, wie eine Aufgabe definiert und eingereiht wird, führt die eingereihte Arbeit aber nicht selbst aus. In Produktion brauchen Sie weiterhin ein Backend oder einen Worker-Prozess, der Aufgaben ausführt; Celery ist eine Option, keine Anforderung des Frameworks. Die Release Notes von Django 6.0 sind unmissverständlich, was die Grenze angeht: Django übernimmt das Erstellen und Einreihen von Aufgaben, stellt aber keinen Worker-Mechanismus bereit, und die Ausführung muss von externer Infrastruktur verwaltet werden, etwa einem eigenen Prozess oder Dienst.

Was Sie bekommen, ist die Schnittstelle:

from django.core.mail import send_mail
from django.tasks import task

@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

email_users.enqueue(...) schickt die Aufgabe an ein konfiguriertes Backend. Die beiden Backends, die mit 6.0 ausgeliefert werden, sind für Entwicklung und Tests gedacht (also nicht das, auf das Sie gehofft haben). Zeitplanung, Wiederholungsintervalle, Retries und Dauerhaftigkeit liegen allesamt außerhalb des Umfangs.

Kevin Renskers, ein praktizierender Django-Entwickler, hat es am schärfsten formuliert in seiner Besprechung von Tasks:

Stattdessen bekamen wir eine Abstraktion ohne Implementierung.

Was die Form angeht, hat er recht. Die Absicht würde ich anders einordnen. In der Abstimmung des Steering Council über DEP 14, dem Django Enhancement Proposal hinter dem Feature, argumentierte Simon Charette, es „sollte etwas sein, in das sich Frameworks wie Celery und RQ einklinken“, und der Autor des Vorschlags beschrieb es als Schnittstelle für Background-Worker statt als Laufzeitumgebung. Die faire Kritik lautet also nicht, dass Tasks kaputt sei. Sie lautet, dass es viel enger ist, als „alles inklusive“ erwarten ließ, und dass die Lücke, die es schließt, die langweilige ist: Ihr Anwendungscode kann Arbeit einreihen, ohne eine bestimmte Queue-Bibliothek zu importieren.

Planen Sie also eine Task-Queue für jedes Django-6.1-Projekt ein, das Retries, geplante Arbeit oder Einblick in Fehlschläge braucht. Das ist derselbe Posten wie vor 6.0, und falls Sie gehofft haben, dieses Release würde ihn aus Ihrem Architekturdiagramm streichen: tut es nicht.

Wenn Sie sich bereits für Django entschieden haben und die Serverschicht lieber nicht von Grund auf zusammenbauen wollen: der Django VPS von Cloudzy gibt Ihnen einen selbstverwalteten Startpunkt mit Django, Gunicorn, Nginx und PostgreSQL, dazu Root-Zugriff, wenn Sie Redis oder Celery brauchen. Der Server bleibt Ihrer im Betrieb: Sie überspringen die Einrichtung auf der leeren Kiste, nicht die Betriebsverantwortung.

LESEN

Python auf einem VPS-Server installieren? | ein Schritt-für-Schritt-Guide

Ist Djangos Async-Unterstützung inzwischen gut genug?

Gut genug, dass „es ist nur synchron“ Sie nicht mehr aufhalten sollte, und nicht gut genug, um darauf eine vollständig asynchrone Datenschicht zu bauen. Beide Hälften stimmen bei 6.1. Welche für Sie gilt, hängt davon ab, was Sie bauen und ob Sie es unter ASGI oder WSGI ausliefern, denn diese Wahl entscheidet, ob Sie einen vollständig asynchronen Request-Stack und effiziente Behandlung langlebiger Verbindungen bekommen.

Die Fähigkeiten stehen nicht zur Debatte. Jede Methode von QuerySet die SQL auslöst, hat eine asynchrone Variante mit dem Präfix a. Die Schleife async for funktioniert über QuerySets hinweg, und die asynchronen Datenbank-APIs umfassen Modellmethoden wie asave() und QuerySet-Methoden wie acreate(). Sie können eine Async-View schreiben, die Queries und nebenläufige ausgehende HTTP-Aufrufe awaitet, ganz ohne Threadpool-Wrapper. Verglichen mit dem Django, über das die „nur synchron“-Kritik geschrieben wurde, ist das ein anderes Framework.

Über das Verhalten entscheidet das Deployment-Protokoll, nicht die Framework-Version, und genau das muss Djangos eigenes Forum immer wieder neu erklären. Der Themenleitfaden zu Async hält fest, dass Async-Views unter einem WSGI-Server in ihrer eigenen, einmaligen Event-Loop laufen, Sie also Async-Funktionen nutzen können, aber „die Vorteile eines Async-Stacks nicht bekommen“.

Hunderte Verbindungen ohne Python-Threads bedienen, langsames Streaming, Long-Polling: dafür braucht es ASGI. Derselbe Code, anderes Nebenläufigkeitsverhalten, und nichts im Framework sagt Ihnen, welches Sie gerade bekommen.

Diese Verwirrung ist langlebig. Ein Nutzer namens tomcypress eröffnete einen Thread im Django-Forum mit der Frage, warum aufeinanderfolgende Requests an eine Async-View nicht alle ihre Hintergrundarbeit ausführten, und Forums-Stammgast KenWhitesell verwies ihn auf die WSGI-Event-Loop. Dieser Austausch stammt von 2021, und daran hat sich bei 6.1 nichts geändert.

Und sie wird auch von außen bestärkt. Die Pro-und-Contra-Seite zu Django bei TechVidvan erzählt Lesern, Django „ist nicht in der Lage, mehrere Anfragen gleichzeitig zu bearbeiten“, was für Django 6.1 falsch ist und genau die Art Behauptung darstellt, die eine Evaluierung beendet, bevor sie beginnt. Nebenläufigkeit fehlt dem Framework nicht; sie wird vom Deployment entschieden.

Der harte Stopp sind Transaktionen, und Djangos eigene Async-Dokumentation sagt es unumwunden:

Transaktionen funktionieren im Async-Modus noch nicht. Wenn Sie ein Stück Code haben, das Transaktionsverhalten braucht, empfehlen wir, dieses Stück als eine einzige synchrone Funktion zu schreiben und sie aufzurufen mit sync_to_async().

Dieselbe Seite stuft bestimmte Kernteile des Frameworks als „async-unsicher“ ein und verhindert ihre Ausführung in einem Async-Kontext, indem sie auslöst: SynchronousOnlyOperation wenn Sie es versuchen. Die Form einer asynchronen Django-6.1-Anwendung ist also: Async-Views und asynchrone Lesezugriffe mit synchronen Inseln überall dort, wo Schreibvorgänge Atomarität brauchen. Machbar, und nicht dasselbe wie ein async-natives Framework. Mein Urteil auf dieser Achse: spürbar besser, nicht fertig, und ein klares Bestanden für alles, was nicht auf Nebenläufigkeit zuerst setzt.

Hat FastAPI Django zur falschen Standardwahl gemacht?

Für eine bestimmte und wachsende Klasse von Projekten: ja. Die Python Developers Survey 2024 von JetBrains und der Python Software Foundation, erhoben im Oktober und November 2024 mit mehr als 30.000 Teilnehmenden, sieht FastAPI bei 38 %, Django bei 35 % und Flask bei 34 % über alle Befragten. Unter denjenigen, die Webentwicklung als Hauptzweck ihrer Python-Nutzung angaben, lag Django bei 61 %, FastAPI bei 56 % und Flask bei 39 %.

Sehen Sie sich diese Frage genau an, bevor Sie sie in ein Planungsmeeting tragen, denn sie erlaubt Mehrfachauswahl. Gefragt wurde, welche Frameworks die Befragten nutzen, nicht welches sie gewählt haben, und ein Entwickler, der einen Django-Monolithen pflegt und nebenbei FastAPI-Services schreibt, zählt in beiden. Das sind keine exklusiven Marktanteile, und niemand hat hier 38 % eines Marktes. Sie zeigen ein gespaltenes Signal: FastAPI lag über alle Befragten vor Django, während Django unter den Befragten, die Python vor allem für Webentwicklung nutzen, weiterhin vor FastAPI lag.

Die Django-eigene Umfrage liefert ein weiteres Signal, und zwar von Leuten, die das Framework bereits nutzen. Die Django Developer Survey 2025, durchgeführt von der Django Software Foundation mit JetBrains über 4.655 gefilterte Antworten, die zwischen November 2024 und Januar 2025 erhoben wurden, fand 82 %, die beruflich Django schreiben, 77 %, die es als ihr meistgenutztes Framework nennen, und 48 %, die mit jedem stabilen Release aktualisieren, gegenüber 40 % ein Jahr zuvor. Selbstselektierte Befragte, es beschreibt also die aktuelle Nutzerbasis und nicht den Markt. Nutzungsbreite und Bindungstiefe sind unterschiedliche Signale, und Djangos zweite Zahl ist gesünder als seine erste.

Die Stellen, an denen FastAPI gewinnt, sind enger und schärfer, als der Abstand in der Umfrage vermuten lässt. Eine typgetriebene API-Oberfläche, in der Ihre Pydantic-Modelle die Validierungsschicht sind und das generierte OpenAPI-Schema der Vertrag ist, schlägt Django plus eine Serializer-Schicht. FastAPI ist auf der Request-Ebene async-nativ, aber seine eigene Dokumentation ist eindeutig : Pfadoperationen lassen sich auf beide Arten schreiben, und ein Handler oder eine Dependency, deklariert mit einem einfachen def , laufen in einem externen Threadpool.

Und ein Dienst ohne Admin, ohne Formulare und ohne Templates schleppt Djangos Batterien als totes Gewicht mit: Sie bezahlen für die Meinungen des Frameworks und nutzen ein Viertel davon. Wenn Sie genau das bauen, ist der Schwung kein Hype und Sie sollten ihm folgen.

Wer sollte Django wählen?

Greifen Sie bei 6.1 zu Django, wenn Admin, Auth, Formulare und ORM den Großteil der anstehenden Arbeit ausmachen: interne Werkzeuge, Marktplätze, Back-Office-SaaS. Es passt auch für ein kleines Team, das all das ab Tag eins braucht, und für ein Team, das jetzt schon wissen muss, wie sein Supportfenster 2029 aussieht.

Produkte, bei denen die Meinungen des Frameworks den Großteil der eigentlichen Arbeit abdecken. Alles mit einer Berechtigungsmatrix und viel CRUD hinter einem Login. Hier ist es der Sinn der Sache und keine Kosten, dass das Framework die strukturellen Entscheidungen trifft, denn genau diese Entscheidungen wären ohnehin der Großteil dessen, was Sie bauen würden.

Kleine Teams, die ab Tag eins produktiv sein müssen. Mit drei Entwicklern und ohne Plattform-Ingenieur fängt das eine Team an, Features zu schreiben, während das andere anfängt, Auth-Bibliotheken zu evaluieren. Ab da wächst der Abstand mit Zinseszins.

Teams, die bereits auf Django sind und die nächsten drei Jahre planen. Django 5.2 gibt Ihnen eine unterstützte Basis bis April 2028, und der jährliche Rhythmus gibt Ihnen danach eine planbare. Ein lesbarer Support-Horizont ist bei der Planung bares Geld wert, und es ist ungewöhnlich, ihn so klar in die Hand gedrückt zu bekommen.

Wer sollte Django nicht wählen?

Wählen Sie Django nicht für eine API mit hohem Durchsatz oder Streaming ohne Admin dahinter: FastAPI ist für diese Projektform die sauberere Standardwahl. Wählen Sie es nicht, wenn Sie dieses Jahr asynchronen Datenzugriff einschließlich Transaktionen brauchen, denn 6.1 hat das nicht. Und wählen Sie es nicht in der Erwartung, dass die Batterien Ihre Hintergrundjobs ausführen.

Eine einzelne API mit hohem Durchsatz oder Streaming, ohne Admin- und ohne Formularfläche. Fast nichts, worin Django gut ist, ist bei dieser Projektform tragend, Sie würden also die Struktur eines ganzen Frameworks pflegen für einen Dienst, der einen Router und einen Validator brauchte.

Teams, die heute vollständig asynchronen Datenzugriff brauchen, Transaktionen eingeschlossen. Django 6.1 unterstützt keine Transaktionen im Async-Modus. Ihre Schreibvorgänge in sync_to_async() einzupacken ist ein legitimes Muster, kein Workaround, dem Sie dieses Jahr entwachsen, und wo das nicht akzeptabel ist, ist es ein Blocker und kein Kratzer.

Teams, die „alles inklusive“ so lesen, als decke es die Ausführung von Hintergrundjobs ab. Tasks bringt keinen Worker mit. Wenn Ihr Plan annahm, 6.0 habe die Queue aus Ihrem Stack entfernt, muss wieder eine Queue in den Plan, bevor Sie sich auf das Framework festlegen.

Welches Web-Framework man zuerst lernen sollte, ist eine andere Frage mit einer anderen Antwort; die FAQ weiter unten hat die Kurzfassung.

Zu wissen, wo Django aufhört, ist das, was den Einstieg sicher macht: Die oben genannten Ausgänge sind vor der Festlegung sichtbar und werden nicht erst danach entdeckt.

Häufig gestellte Fragen