Django seit
10+ Jahren im Einsatz
Backend-Systeme
100+ gebaut
Heutiger Schwerpunkt
APIs & LLM-Anbindung
Das Django-Ökosystem — und was davon was ist
Was man zu Django dazunimmt, heißt Django-App — genauer: wiederverwendbare App. Technisch ist das ein Python-Paket, das inINSTALLED_APPSeingetragen wird und dann Modelle, Ansichten und Vorlagen mitbringt. „Plugin" oder „Add-on" sagt in der Django-Welt niemand; das kommt aus dem WordPress- und TYPO3-Umfeld, wo es eine andere Mechanik beschreibt.
Die Namen, die in diesem Zusammenhang immer fallen, gehören allerdings zu vier verschiedenen Gattungen — und diese Unterscheidung entscheidet darüber, wie sehr man sich bindet:
| Name | Was es wirklich ist | Wie stark bindet es |
|---|---|---|
| Django Admin | Eingebauter Bestandteil von Django, kein Zusatz | gar nicht — ist immer da |
| Django REST Framework | Bibliothek für HTTP-Schnittstellen | mittel, ersetzbar |
| Django Ninja | Jüngere Alternative zu DRF, typannotiert | mittel, ersetzbar |
| Celery | Eigenständiges System für Hintergrundaufgaben | gering, nicht Django-spezifisch |
| Wagtail | Vollständiges CMS auf Django-Basis | stark — man baut darin, nicht damit |
| Django CMS | Vollständiges CMS auf Django-Basis | stark — man baut darin, nicht damit |
Der letzte Punkt wird regelmäßig unterschätzt. Eine Bibliothek wie DRF tauscht man im laufenden Betrieb aus, wenn es sein muss. Ein CMS wie Wagtail oder Django CMS ist eine Architekturentscheidung: Inhalte, Rechte und Redaktionsoberfläche liegen darin. Wagtail nehmen wir, wenn Redaktion und Entwicklung dasselbe Modell teilen sollen — es ist näher an gewöhnlichem Django und headless gut zu betreiben. Django CMS nehmen wir, wenn Redakteur:innen Seiten frei zusammensetzen sollen, mit Plugin-System, Mehrsprachigkeit und Freigabe-Workflow. Wer nur gelegentlich einen Text ändert, braucht keins von beiden — dann ist der Inhalt im Code besser aufgehoben als in einem System, das gepflegt werden will.
Die Apps, die bei uns in fast jedem Projekt mitlaufen, sind unspektakulär und genau deshalb wichtig: django-allauth für Anmeldung und Fremdlogin, django-storages für Dateien im Objektspeicher, django-filter für Listenfilter, whitenoise für statische Dateien, pytest-django für Tests. Jede weitere App ist eine Abhängigkeit, die jemand aktuell halten muss — deshalb prüfen wir bei jeder, ob der eingesparte Aufwand größer ist als die Pflege über fünf Jahre.
Django REST Framework vs. Django Ninja
| Kriterium | Django REST Framework | Django Ninja |
|---|---|---|
| Reife | Seit 2011, sehr stabil | Jünger, aber produktionstauglich |
| Schema-Definition | Serializer-Klassen | Pydantic-Schemas aus Typannotationen |
| OpenAPI | Über drf-spectacular | Eingebaut |
| async | Eingeschränkt | Nativ unterstützt |
| Berechtigungen | Ausgereiftes Permission-System | Schlanker, mehr Eigenbau |
| Ökosystem | Sehr groß | Überschaubar |
| Unsere Wahl bei | Großen Systemen, komplexen Rechten | Schlanken APIs, LLM-Endpunkten |
In gemischten Projekten setzen wir beides parallel ein: DRF für die gewachsene Haupt-API mit ihren Rechten und Serializern, Ninja für neue, schmale Endpunkte, bei denen async und ein sauberes Schema wichtiger sind als Kompatibilität mit dem Bestand.
Django-Stack im Detail
Das Datenmodell zuerst
Die meisten Django-Projekte, die später wehtun, haben ein Datenmodell, das zu früh festgezurrt oder zu lange offen gelassen wurde. Wir investieren die erste Woche fast vollständig hier.
Migrationen mit Rückweg
Spaltenumbenennungen und Typänderungen laufen bei uns zweistufig: erst additiv ausrollen, dann umstellen, dann aufräumen. So bleibt jedes Deployment rückrollbar.
N+1 früh sichtbar machen
Der ORM macht Abfragen bequem und Performanceprobleme unsichtbar. Wir prüfen Abfragezahlen in Tests, damit ein N+1-Problem im Review auffällt und nicht in Produktion.
Wofür wir welche Bausteine einsetzen
Django Admin
Stammdatenpflege, Support-Zugriff, interne Recherche. Angepasst mit eigenen Actions und Filtern — aber nicht als Prozesswerkzeug.
Celery & Redis
E-Mails, PDF-Erzeugung, Importe, LLM-Aufrufe. Mit Wiederholungen, Zeitlimits und einer Warteschlange je Priorität.
Django Channels
WebSockets für Live-Aktualisierungen und Chat. Für reines Server-zu-Client-Streaming reichen oft Server-Sent Events.
HTMX
Interaktivität ohne Frontend-Projekt: Teilaktualisierungen, Formulare, Modals — serverseitig gerendert.
pytest & factory_boy
Testdaten als Factories statt Fixtures, Abfragezahl-Assertions, Tests gegen eine echte PostgreSQL statt SQLite.
Deployment
Docker, Gunicorn oder Uvicorn, Migrationen als eigener Schritt, Health-Checks, WhiteNoise oder CDN für statische Dateien.
Wann Django nicht die richtige Wahl ist
Reine Echtzeit-Systeme
Wenn fast alles über WebSockets läuft und kaum Datenmodell dahintersteht, ist Django viel Rahmen für wenig Nutzen. Ein schlanker async-Dienst passt dann besser.
Sehr schmale Microservices
Ein Dienst mit zwei Endpunkten und ohne eigene Datenbank braucht kein ORM, kein Admin und kein Migrationssystem. FastAPI ist hier die ehrlichere Wahl.
Reine Datenverarbeitung
Batch-Pipelines ohne Weboberfläche laufen besser als eigenständige Python-Prozesse. Django dazwischen erzeugt nur Kopplung, die niemand braucht.
Klassische Redaktions-Websites
Wenn es überwiegend um Inhaltspflege geht, ist ein spezialisiertes CMS oft schneller am Ziel — Wagtail oder Django CMS, wenn es Python bleiben soll.
Häufige Fragen zur Django-Entwicklung
Django REST Framework oder Django Ninja?
Django REST Framework, wenn ihr Serializer, ViewSets, ein ausgereiftes Berechtigungssystem und ein großes Ökosystem an Erweiterungen braucht — das ist bei den meisten größeren Projekten der Fall. Django Ninja, wenn ihr eine schlanke, typannotierte API mit automatischer OpenAPI-Dokumentation und async-Unterstützung wollt und auf DRFs Serializer-Schicht verzichten könnt. Ninja fühlt sich an wie FastAPI innerhalb von Django.
Taugt der Django-Admin als Backoffice für echte Nutzer?
Für interne Teams bis etwa zwanzig Personen: ja, und er spart Wochen an Entwicklungszeit. Für Kundschaft oder Nutzende ohne Schulung: nein. Der Admin kennt keine feingranularen Rechte auf Feldebene, keine mehrstufigen Freigaben und keine geführten Abläufe. Wir setzen ihn bewusst für Stammdatenpflege und Support ein und bauen alles, was Prozesse abbildet, als eigene Oberfläche.
Wann braucht ein Django-Projekt Celery?
Sobald etwas länger dauert als eine HTTP-Antwort dauern darf: E-Mail-Versand, PDF-Erzeugung, Importe, LLM-Aufrufe, Berichte. Für rein zeitgesteuerte Aufgaben ohne Nebenläufigkeit reicht oft ein Cronjob mit einem Management-Command — das ist deutlich weniger Betriebsaufwand. Celery lohnt sich, wenn ihr Wiederholungen, Priorisierung und Ergebnisverfolgung braucht.
Ist Django für async-Anwendungen geeignet?
Inzwischen ja, aber mit Einschränkungen. Views, Middleware und der ORM unterstützen async, das Ökosystem ist aber noch nicht durchgängig. Für WebSockets nutzen wir Django Channels, für stark nebenläufige API-Teile stellen wir eher einen FastAPI-Dienst daneben, der sich Datenbank und Modelle mit Django teilt. Das ist meist pragmatischer, als ein gewachsenes Django-Projekt vollständig auf async umzustellen.
Wie migriert man ein altes Django-Projekt auf eine aktuelle Version?
In Schritten über die LTS-Versionen, nicht in einem Sprung. Vorher braucht es eine Testsuite, die die kritischen Abläufe abdeckt — ohne die ist eine Migration Ratespiel. Danach Version für Version, jeweils mit grüner CI, und die Abhängigkeiten in derselben Reihenfolge nachziehen. Für ein mittelgroßes Projekt aus einer alten Version sind das erfahrungsgemäß zwei bis sechs Wochen.
Django mit React oder mit HTMX?
HTMX, wenn die Oberfläche im Kern serverseitig gerendert bleiben kann und ihr punktuell Interaktivität braucht — das spart ein komplettes Frontend-Projekt samt Build-Kette. React, wenn ihr komplexen Client-Zustand habt, Offline-Fähigkeit braucht oder eine App-artige Oberfläche wollt. Wir bauen beides und raten in etwa der Hälfte der Fälle zu HTMX, weil der Aufwand dramatisch niedriger ist.
Wie deployt man Django sinnvoll?
Gunicorn oder Uvicorn hinter einem Reverse Proxy, in Docker, mit PostgreSQL und Redis als Diensten daneben. Statische Dateien über WhiteNoise oder ein CDN, Migrationen als eigener Schritt vor dem Rollout, Health-Checks für die Bereitstellungsprüfung. Ob das auf Kubernetes, einer Plattform wie Railway oder einem einzelnen gut gepflegten Server läuft, ist eine Frage eurer Größe — nicht des Frameworks.
Unsere Leistungsseiten im Überblick
Wir trennen bewusst zwischen der Frage, wen man beauftragt, und der Frage, wie entwickelt wird — je nachdem, wo ihr gerade steht, ist eine andere Seite die richtige.
Überblick
Software Agentur — Individualsoftware, Auswahl, Kosten, Standard vs. Eigenbau
Mehr erfahren →Beauftragung
Python Agentur — Auswahl, Kosten, Leistungen, LLM- und Agenten-Projekte
Mehr erfahren →Berlin
Python-Agentur Berlin — Vor Ort in Prenzlauer Berg, Anbietertypen, Berliner Referenzen
Mehr erfahren →Umsetzung
Python Entwicklung — Entwickler, Arbeitsweise, Code-Qualität, Übergabe
Mehr erfahren →Beauftragung
Django Agentur — Django und Django CMS als Projekt vergeben
Mehr erfahren →Berlin
Django-Agentur Berlin — Bestandsaufnahme vor Ort, Übernahme laufender Systeme
Mehr erfahren →Web
Website erstellen lassen — Next.js und Vercel statt Baukasten, mit eingebauter Messung
Mehr erfahren →Bestand
Website-Relaunch — TYPO3 oder WordPress ablösen, ohne Sichtbarkeit zu verlieren
Mehr erfahren →KI
KI-Agenten entwickeln — Abgegrenzte Aufgabe, eigene Werkzeuge, prüfbares Ergebnis
Mehr erfahren →CMS
Plone Agentur — Enterprise-CMS für Institute, Migration auf Plone 6
Mehr erfahren →Weiterführende Artikel
CMS
Wagtail oder Django CMS? Der ehrliche Vergleich
Artikel lesen →Use Case
Kundenportal entwickeln: Leitfaden und Budgets
Artikel lesen →Framework
Django vs. Flask vs. FastAPI: Das richtige Python-Framework
Artikel lesen →API
Python API Entwicklung: REST und GraphQL mit Django und FastAPI
Artikel lesen →AI-Backend
Django vs. FastAPI für AI-Backends: Wann nimmt man was?
Artikel lesen →LLM
LLM-APIs in Django einbinden: Schritt für Schritt
Artikel lesen →Streaming
Streaming-LLM-Antworten mit Django und React: Server-Sent Events
Artikel lesen →Frontend
Django und React — ist das eine gute Kombination?
Artikel lesen →RAG
RAG-System mit Python und Django aufbauen
Artikel lesen →Vektor-DB
Vektordatenbanken im Vergleich: pgvector, Pinecone, Weaviate
Artikel lesen →/ Hintergrund & Wissen
Der Django-Admin: mächtig und oft überstrapaziert
Der Admin ist eines der stärksten Argumente für Django. Er entsteht praktisch von selbst aus dem Datenmodell und ersetzt in vielen Projekten Wochen an Backoffice-Entwicklung. Genau deshalb wird er regelmäßig überdehnt.
Die Grenze verläuft dort, wo aus Datenpflege ein Prozess wird. Sobald mehrere Rollen nacheinander etwas freigeben, Felder je nach Zustand sichtbar sein sollen oder Nutzende ohne Schulung damit arbeiten, wird der Admin zur Bastelei. Wir ziehen die Linie früh und bauen Prozesse als eigene Ansichten — der Admin bleibt für Stammdaten und Support.
Hintergrundjobs: Celery oder doch nur ein Cronjob
Celery ist der Standard für asynchrone Aufgaben in Django, bringt aber Betriebsaufwand mit: ein Broker, Worker-Prozesse, Überwachung, ein Ergebnis-Backend. Für viele Projekte, die es einsetzen, wäre ein Management-Command im Cron die einfachere Lösung gewesen.
Unsere Faustregel: Solange Aufgaben zeitgesteuert laufen, nacheinander abgearbeitet werden können und ein Fehlschlag bis zum nächsten Lauf warten darf, reicht Cron. Sobald Aufgaben aus einer Nutzeraktion entstehen, Priorität brauchen oder ihr Ergebnis nachverfolgt werden soll, lohnt Celery.
Was in beiden Fällen dazugehört: Zeitlimits, eine begrenzte Zahl an Wiederholungen und Protokollierung. Ein Job ohne Zeitlimit ist ein Job, der irgendwann eine Datenbankverbindung für Stunden blockiert.
Django-Versionen aktuell halten
Django hat einen verlässlichen Veröffentlichungsrhythmus mit LTS-Versionen, und genau daran sollte man sich hängen. Projekte, die zwei LTS-Sprünge zurückliegen, sind nicht nur ein Sicherheitsrisiko — sie werden auch teuer, weil das Abhängigkeitsökosystem sie nicht mehr unterstützt.
Die Migration ist selten am Django-Code aufwendig, sondern an den Abhängigkeiten drumherum. Deshalb reduzieren wir in gewachsenen Projekten zuerst die Zahl der Fremdpakete, bevor wir Versionen anheben. Jedes Paket, das man loswird, ist eines, das bei der nächsten Migration keine Arbeit macht.