Django shipped two feature releases and rewrote its entire release cadence in the eight months between December 2025 and August 2026.
That landed on a framework whose reputation hasn't moved much since 2023: the batteries-included Python framework that is productive, opinionated, sync-only, and losing ground to FastAPI. The async label is stale, and the popularity story is more complicated than the headline numbers suggest.
So here is where I land on whether Django is still worth it at 6.1: a verdict with a rating, the project shapes it fits, and the ones where FastAPI is now the better call.
The Short Version
Yes, with conditions. Django 6.1 remains the strongest default when the admin, auth, forms, and ORM are most of the work, and the async gap has narrowed enough that "sync-only" is no longer a reason to rule it out. It's wrong for a single high-concurrency API with no admin surface. 4 out of 5.
- The bundle is the thing you're buying. The ORM, migrations, session auth with permissions, a form layer, and a generated admin arrive together and already integrated, not as five libraries plus the seams between them.
- Background jobs are the weak axis. Django 6.0's Tasks framework gives you a decorator and an enqueue call but no worker, so Celery or an equivalent remains a decision you make yourself.
- Async is much better and clearly unfinished. Django supports async views and async ORM calls, but transactions do not work in async mode. Under WSGI, async views can still run concurrent async I/O within a request, but you do not get the benefits of a fully async request stack; long-running requests and high connection concurrency require ASGI.
- Planning past 2027 got easier. From January 2028, Django ships one feature release a year, each carrying three years of support, and the "LTS" label goes away because every release now gets that commitment.
- Right for admin-heavy and CRUD-heavy products and for small teams. Wrong for a single high-throughput or streaming API with no admin or forms surface, where FastAPI is the more natural choice.
How I put this review together: This is an evaluation of Django 6.1 built from the project's own release notes and documentation, the Django Software Foundation's August 2026 governance announcement, the 2024 JetBrains/PSF and 2025 Django developer surveys, and named practitioners writing publicly about their own production experience. I did not run a multi-week production trial for this piece, and there are no benchmarks here: nothing was load-tested. Django is free and BSD-licensed, and I have no relationship with the project.
What Actually Changed in Django Since 2025?
Django 6.0 landed on December 3, 2025 with a first-party Tasks framework and other core additions. The async ORM interface was already older: Django 4.1 introduced asynchronous QuerySet operations in 2022. Django 6.1 became current stable on August 5, 2026. Then on August 10, 2026, the project announced one feature release a year from January 2028, three years of support for each release, and the end of the LTS label.
The 6.1 release notes confirm that 6.1 supports Python 3.12, 3.13, and 3.14, with mainstream support ending in April 2027 and extended support in December 2027.
The version numbers change with it. They carry the year, so Django 2028, then Django 2029 (at least "what version are you on" gets easier to answer). The three years break down as one year of mainstream bugfixes followed by two of security and data-loss fixes, which is what LTS used to mean, so the label goes away.
That leaves an awkward window for a project starting today. Django 5.2 is the current LTS, supported until April 2028. Django 6.1 is current stable, but its extended support ends in December 2027, about four months before Django 5.2's support window ends in April 2028.
So: chasing the longest support window means starting on 5.2. Wanting the Tasks framework and the latest 6.x features means starting on 6.1 and accepting another upgrade sooner. Neither is wrong, and the awkward choice disappears when Django 6.2 LTS arrives in April 2027.
I read the cadence change as a good sign. Projects in decline quietly stretch their support promises; they don't restructure them in public with a dated plan. This one simplified a commitment it was already keeping.
What Django Still Does Better Than Anything Else
Start a Django 6.1 project and you have working session auth with a permission system, a form layer that validates and renders, a migration system tied to your models, the ORM, and a generated admin, before you write a single feature. That is the whole pitch, and it's the part of Django that hasn't needed to change.
The value is not that those pieces exist. It's that they were designed against each other. The same model permissions feed the admin, and a model change generates the migration and updates the admin form in the same breath.
Assembling equivalent coverage from independent libraries gets you there eventually. It also gets you a permanent maintenance surface at every seam, and the seams are where the bugs live.
The admin is a staff tool. The admin reference says its recommended use is limited to an organization's internal management tool and that it is not intended for building your entire front end around. Model permissions control what staff users can do once they are inside, and getting inside at all requires is_staff. Treat that as a constraint and it's a good one: you get a competent internal back office for free, and you don't get a customer-facing UI, so nobody is tempted to ship one.
The security defaults are the other half of the same argument. CSRF protection, SQL parameterization through the ORM, XSS escaping in templates, and clickjacking protection are on by default rather than things a senior developer has to remember to ask for in review. A small team inherits choices made by people who have read a decade of security reports.
Then there's age. It gets read as a liability; I read it as the ecosystem argument. Django REST Framework exists and is boring in the way you want infrastructure to be boring.
So do mature packages for the problems you hit in month four: filtering, throttling, storage backends, multi-tenancy patterns, audit trails. And when a problem is unusual enough that no package covers it, there is usually a fifteen-year-old mailing list thread about it. On breadth I don't think anything else in Python is close, and this axis is why anyone picks Django in the first place.
Where Django Falls Short
Django still lacks comprehensive first-party typing across the framework, the conservative pace leaves gaps that "batteries included" doesn't warn you about, and the 6.0 Tasks framework has no worker. Those are the three shortfalls at 6.1. The typing gap is the one that annoys you daily; Tasks is the one that changes your architecture diagram.
You still assemble much of the typing story from third-party tooling instead. django-stubs provides type stubs plus a custom mypy plugin for Django's dynamic behavior. Its current documentation lists full mypy support and basic support for pyright, pyrefly, and ty. That is a better situation than it used to be, but it is still a separate compatibility layer rather than comprehensive first-party typing in Django itself.
Coming from a framework built around type hints, that's a measurable regression in day-to-day editor experience.
The conservative pace is a cost as well as a virtue. Django adds things carefully and late, which is why the framework you learned in 2019 is the one you can read today. It's also why the batteries stop where they stop: no WebSocket layer in core, no scheduler, no opinion about async task orchestration. Cross one of those lines and you're assembling things yourself again.
Does Django 6 Still Need Celery?
Not specifically Celery. Django 6.0's Tasks framework standardizes how a task is defined and enqueued, but it does not run queued work itself. In production, you still need a backend or worker process that executes tasks; Celery is one option, not a framework requirement. Django 6.0's release notes are blunt about the boundary: Django handles task creation and queuing but does not provide a worker mechanism, and execution must be managed by external infrastructure, such as a separate process or service.
What you get is the interface:
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(...) sends the task to a configured backend. The two backends that ship with 6.0 are meant for development and testing (so, not the one you were hoping for). Scheduling, recurrence, retries, and durability are all outside the scope.
Kevin Renskers, a working Django developer, put it sharpest in his review of Tasks:
Instead, we got an abstraction without an implementation.
He's right about the shape. I'd frame the intent differently. In the Steering Council vote on DEP 14, the Django Enhancement Proposal behind the feature, Simon Charette argued it "ought to be something that framework like Celery and RQ plug into," and the proposal's author described it as a background workers interface rather than a runtime. So the fair criticism isn't that Tasks is broken. It's that it is much narrower than "batteries included" led people to expect, and the gap it closes is the boring one: your app code can enqueue work without importing a specific queue library.
So budget for a task queue on any Django 6.1 project that needs retries, scheduled work, or visibility into failures. That's the same line item it was before 6.0, and if you were hoping this release would delete it from your architecture diagram, it doesn't.
If you've already decided Django fits and would rather not assemble the server layer from scratch, Cloudzy's Django VPS gives you a self-managed starting point with Django, Gunicorn, Nginx, and PostgreSQL, plus root access when you need Redis or Celery. It's still your server to operate; you're skipping the blank-box setup, not the operational responsibility.
Is Django's Async Support Good Enough Now?
Good enough that "it's sync-only" should no longer stop you, and not good enough to build a fully async data layer on. Both halves are true at 6.1. Which one applies to you depends on what you're building and on whether you serve it under ASGI or WSGI, because that choice determines whether you get a fully asynchronous request stack and efficient handling of long-lived connections.
The capability side is not in dispute. Every QuerySet method that triggers SQL has an a-prefixed async variant, async for works across QuerySets, and the async database APIs include model methods such as asave() and QuerySet methods such as acreate(). You can write an async view that awaits queries and concurrent outbound HTTP calls without a threadpool wrapper. Compared to the Django the "sync-only" critique was written about, that's a different framework.
What decides the behavior is the deployment protocol, not the framework version, and it's the part Django's own forum keeps having to re-explain. The async topic guide states that under a WSGI server, async views run in their own one-off event loop, so you can use async features but "you will not get the benefits of an async stack."
Servicing hundreds of connections without Python threads, slow streaming, long-polling: those require ASGI. Same code, different concurrency behavior, and nothing in the framework tells you which one you're getting.
That confusion has a long life. A user posting as tomcypress opened a thread on Django's forum asking why consecutive requests to an async view weren't all running their background work, and forum regular KenWhitesell pointed him at the WSGI event loop. That exchange is from 2021 and nothing about it has changed at 6.1.
It's also being reinforced from outside. TechVidvan's Django pros-and-cons page tells readers Django "is not capable of handling multiple requests at the same time," which is wrong about Django 6.1 and is the kind of claim that ends an evaluation before it starts. Concurrency isn't something the framework lacks; it's something the deployment decides.
The hard stop is transactions, and Django's own async documentation says it plainly:
Transactions do not yet work in async mode. If you have a piece of code that needs transactions behavior, we recommend you write that piece as a single synchronous function and call it using
sync_to_async().
The same page classifies certain key parts of the framework as "async-unsafe" and blocks them from running in an async context, raising SynchronousOnlyOperation if you try. So the shape of a Django 6.1 async application is async views and async reads with synchronous islands wherever writes need atomicity. Workable, and not the same thing as an async-native framework. My take on this axis: meaningfully better, not finished, and a clear pass for anything that isn't concurrency-first.
Has FastAPI Made Django the Wrong Default?
For a specific and growing class of project, yes. The 2024 Python Developers Survey from JetBrains and the Python Software Foundation, collected across October and November 2024 with more than 30,000 participants, put FastAPI at 38%, Django at 35%, and Flask at 34% across all respondents. Among respondents who selected web development as what they use Python for the most, Django was at 61%, FastAPI at 56%, and Flask at 39%.
Look at that question carefully before you take it to a planning meeting, because it's multi-select. Respondents were asked which frameworks they use, not which one they picked, and a developer maintaining a Django monolith while writing FastAPI services counts in both. These are not exclusive market shares, and nobody has 38% of a market here. What they show is a split signal: FastAPI led Django across all respondents, while Django still led FastAPI among respondents who primarily use Python for web development.
The Django-specific survey adds another signal from the people already using the framework. The Django Developer Survey 2025, run by the Django Software Foundation with JetBrains across 4,655 filtered responses collected between November 2024 and January 2025, found 82% writing Django professionally, 77% naming it their most-used framework, and 48% upgrading with every stable release, up from 40% a year earlier. Self-selected respondents, so it describes the current user base rather than the market. Breadth of usage and depth of commitment are different signals, and Django's second number is healthier than its first.
The places FastAPI wins are narrower and sharper than the survey spread suggests. A type-driven API surface, where your Pydantic models are the validation layer and the generated OpenAPI schema is the contract, beats Django plus a serializer layer. FastAPI is async-native at the request layer, but its own documentation is explicit that path operations can be written either way: a handler or dependency declared with a plain def runs in an external threadpool.
And a service with no admin, no forms, and no templates carries Django's batteries as dead weight: you're paying for the framework's opinions and using a quarter of them. If that's what you're building, the momentum isn't hype and you should follow it.
Who Should Choose Django?
Reach for Django at 6.1 when the admin, auth, forms, and ORM are most of the work you're about to do: internal tools, marketplaces, back-office SaaS. It's also right for a small team that needs those things working on day one, and for a team that needs to know now what its support window looks like in 2029.
Products where the framework's opinions cover most of the actual work. Anything with a permissions matrix and a lot of CRUD behind a login. Here the framework making the structural choices is the point rather than a cost, because those choices are most of what you'd be building anyway.
Small teams that need to be productive on day one. With three developers and no platform engineer, one team starts writing features while the other starts evaluating auth libraries. That gap compounds from there.
Teams already on Django planning the next three years. Django 5.2 gives you a supported floor through April 2028, and the annual cadence gives you a predictable one after that. A legible support runway is worth money at planning time, and it is unusual to be handed one this clearly.
Who Shouldn't Choose Django?
Don't pick Django for a high-throughput or streaming API with no admin behind it: FastAPI is the cleaner default for that shape of project. Don't pick it if you need async data access including transactions this year, because 6.1 doesn't have it. And don't pick it expecting the batteries to run your background jobs.
A single high-throughput or streaming API with no admin and no forms surface. Almost nothing Django is good at is load-bearing for this shape of project, so you'd be maintaining a whole framework's structure for a service that needed a router and a validator.
Teams that need fully async data access, including transactions, today. Django 6.1 does not support transactions in async mode. Wrapping your writes in sync_to_async() is a legitimate pattern, not a workaround you'll grow out of this year, and where that's unacceptable it's a blocker rather than a papercut.
Teams reading "batteries included" as covering background job execution. Tasks does not ship a worker. If your plan assumed 6.0 removed the queue from your stack, the plan needs a queue back in it before you commit to the framework.
Choosing which web framework to learn first is a different question with a different answer; the FAQ below has the short version.
Knowing where Django stops is what makes it safe to start: the exits above are visible before you commit rather than discovered after.
Frequently Asked Questions
Is Django Dead?
No. Django shipped two feature releases between December 2025 and August 2026, and published a restructured release plan running into the 2030s. FastAPI has grown quickly and led Django 38% to 35% across all respondents in the 2024 Python Developers Survey, while Django led 61% to 56% among respondents who primarily use Python for web development. Fast growth by a newer framework and the death of an older one are different claims.
Is Django Good for Beginners?
Yes, with the caveat that it is the most to learn at once. Django's breadth is what makes it productive, and it means a beginner runs into the ORM, migrations, the template layer, and the admin before shipping anything. The contrarian case is worth reading: a Bite Code! post argues beginners should start with Django precisely because its defaults prevent architectural mistakes a minimal framework leaves you to make alone.
Is Django Faster Than Flask?
There's no universal answer. No benchmark was run for this review, and I wouldn't trust one without knowing its workload and deployment. In many applications, database queries, N+1s, and external API calls matter more than framework overhead. If raw request throughput is important to the decision, benchmark the application and server configuration you actually plan to run.
Which Django Version Should You Start a New Project On?
Start on 5.2 if the longest support window matters most: it's the current LTS, supported until April 2028. Start on 6.1 if you want the Tasks framework and the latest 6.x features, accepting mainstream support to roughly April 2027 and extended support to December 2027, then planning an upgrade to Django 6.2 LTS when it arrives in April 2027. Django 6.2 is scheduled for extended support through April 2030. From January 2028 onward, every annual feature release carries three years of support.
Should You Learn Django or FastAPI First?
Learn whichever matches the work you want to do. Django teaches you how a full web application fits together: data modeling, migrations, auth, forms, templates, and the admin, with the structure decided for you. FastAPI teaches you typed API design and async Python with almost nothing decided for you. Neither is the beginner-friendly option in the abstract, and picking the one closer to your target job beats picking the easier one.
Discussion
Comments
Sign in to join the discussion.