Please - save the hyperbole. There are many of us out here who couldn’t care less whether or not async-Django even exists, and I know a number of people who do care - but their projects are such that they don’t need to. (Their issues don’t warrant it.)
I’ve been hearing any number of these “predictions of doom” over the past 10 years on a variety of subjects, where “Django needs to do ‘X’ to survive.” And yet, Django continues to move along well despite doing virtually none of them.
Yes, there are situations that are improved by it. But until someone can demonstrate that there is a real global value to this change, I don’t buy it.
<opinion>
If Instagram can effectively run on sync-Django, I think the universe of people needing to go full async is probably smaller than you think. </opinion>
It’s not that hyperbolic from where I stand, but I respect that my experience may not align with everyone’s.
I’m constantly dealing with my teams asking to switch to FastAPI for new projects and/or spin services out of the Django monolith so they can avoid function coloring problems that are increasingly leaning in the other direction with more websockets, parallel LLM calls, streaming responses, etc in modern web development.
Perhaps you have a different experience but I’m seeing first-hand folks throw up their hands and try out the alternatives. Inevitably when they do they are disappointed with the lack of batteries in that ecosystem, but over time I expect that gap will diminish.
Anyway, “hyperbole” aside, I still believe the case for shifting the performance penalty to the sync side in order to achieve a true async ORM API is a smart compromise if the other ideas (e.g. code generation) aren’t going to work out. Again it’s not a big penalty and there’s an upgrade path that unlocks even better performance.
For what it’s worth, I believe as of a few years ago Instagram has gone full async (and they don’t use the sync Django ORM anymore):
To my knowledge as a Meta employee (though in a completely different department*), Instagram’s Django backend has been async for at least the last half-decade when I joined the company. They may be on an “old” version of Django but it’s a highly-modified hard fork of Django that at this point shares very little with upstream (e.g. I believe they deleted the Django ORM some time ago) and doesn’t even use vanilla CPython.
Though I agree with the sentiment of your opinion, asynchronous programming is not needed for the overwhelming majority of Django deployments. It has some nicer properties beyond scaling though: cancellation and a lower mental burden for concurrency come to mind.
*: I work on Django in my personal capacity because I use it for personal projects and I found it to be a very welcoming community, nothing to do with my work where I don’t write much python.
I’m very much interested in async Django too. Is the needed work put into some kind of plan/milestones? I’d be very happy to take some part and contribute. Cheers!
I’m not sure if this use case is relevant, but as the maintainer of django-socio-grpc, I can say that a fully async ORM would be a real game-changer. Since we don’t use ASGI or WSGI but rather gRPC’s asynchronous server, there is only a single thread.
In this scenario, every sync_to_async call blocks the entire server’s request handling. Of course, load balancing and other systems help mitigate this, but the fact that a single heavy database query can block the whole server is a significant drawback.
Not to mention developers who don’t fully understand sync_to_async and wrap entire functions instead of just ORM calls to simplify their code.
Because of this, my former company is considering migrating to a natively async framework.
I completely understand that Django, as a project, doesn’t have to adapt to secondary projects or fix implementation issues of third-party frameworks or businesses. However, what I want to highlight is that some developers (like myself) might want to complement Django (because it’s their favorite framework) with natively async tools in the future, and the lack of a fully async ORM is a real blocker.
When I started django-socio-grpc, I was betting on Django becoming fully async within five years. Like any bet, if this one doesn’t pay off, it’s on me. However, as a CTO or architect, if Django decides not to support a fully async ORM, I think that if I have to choose a framework for high-performance multi-service communication, I won’t be able to choose Django—even if I want to. (And yes with gRPC as transport layer, django is relevant for high-performance multi-service communication)
@fcurella’s work on adding async cursor support is relevant to this, and likely addressable. ()
If I had to opine on Where are we? I’d likely say, we’ve gone roughly as far as we can without making the ORM fully async-aware (at least as an option), so addressing that now bubbles to the top of the list. Async cursors, then looking at @rtpg’s code-gen proposal (as a possible route for working it through the ORM API) are what I see as the next logical steps.
Like Ken, I’ve heard stories of Django’s demise for… well… as long as I’ve be using Django. Folks always want it to move faster. Truth be told, Django doesn’t do that. Its pace is more reserved. I’ve used the term “glacial” about it, but as (IIRC) @andrewgodwin once said to me, “Did you ever try to stop a glacier?”
We’ll continue, and we’ll get there. No problem if folks want to use other frameworks. Each has their strengths. That’s good! The error is in thinking that one solution will serve for all, in all cases. That’s unlikely.
Is there any reason not to make Django an async only framework?
Python is a language with great async support and has been for going on a decade now. I’ve been writing blue/red code 2014/2015 and it’s never going to be a good experience.
Is there any reason not to make Django an async only framework? In 2025? I can’t think of one that couldn’t be keyword search/replaced into argument for Python 2.x support continuing indefinitely.
This feels like a good opportunity to move forward and move on. Or at least to make the decision to start channeling the glacier in that direction.
Async code is significantly more complex to reason about than sync code. That alone is enough of a reason. If folks want async only there are plenty of options out there catering to that.
Django’s commitment to backwards compatibility means we’d never just drop sync support, and the millions of projects out there built on it.
I don’t know that this is as true today as it was. In 2025 it feels like the world has come to accept async as common pattern and async/await syntax is great. Experience is telling me that ten years from now sync-first code with async grafted on will create more complexity, fragility, and confusion than a well documented sync-to-async migration plan would.
There’s noting out there like Django. I’ve been using it daily since early-2008, I’m fully invested.
The same could be said of the Python2/3 migration. Yeah, keep sync support, but go async-first instead of the other way around. I plan to be using Django in 2035, what does that framework look like?
If I wanted to stop a glacier I would change the environment around it and watch it melt.
Yeah, I neither think Django going async-only is realistic or desirable. Nor do I think it’s an existential problem if that doesn’t happen. (Indeed not being async only is a selling point… see “not desirable”)
“…melt…” — again, Django’s been on the point of death for as long as I’ve been using it, if one were to believe the comments. It’s always more dramatic in thought than reality. (I should start a log of Things Django must do immediately or it will die.)
It is great for those applications that benefit from that type of pattern.
It is horrible for the applications that don’t.
I never want to be in a position again where I have to evaluate some complex chunk of code to avoid having the event loop be stalled because the processing thread was busy.
Django is OpenSource. It would be perfectly acceptible to fork it and modify it to make a completely async-first Django - maybe call it “AsyncGo”?
Hopefully 90% of what it looks like today, and still running the same effective applications that I’ve been running since 2015.
Not everyone performs operations in their views that are parallelizable by I/O operations. Functionality that is primarily CPU bound does not benefit from an async approach.
As I clarified in my previous post, async-first, not async-only. I shouldn’t have used async-only in my first post, it’s too easy to get stuck on that and ignore all other points. Again, stipulated, sync stays.
Is there a reason why Django shouldn’t move in the direction of being async-first (not async-only) while maintaining sync support?
The quote about glaciers assumes the inevitability of a glacier’s momentum. My counterpoint: That’s not how glaciers work.
Q: “Have you ever tired to stop a glacier?”
A: “No, but here’s how I’d do it.”
Like I said, I plan to be using Django in 2035. I’m not saying that you must do this or must do that, or Django will die. Who thinks like that? I don’t.
In my last comment I asked “Why shouldn’t Django be async-first?” The question was ignored.
I have two issues with Django:
REST APIs. I’ve been maintaining a project since 2010. No part of that project has had to be thrown out/completely rewritten once, let alone multiple times, except for the REST API views, serializers, and tests. I’d like a django.contrib.rest package that feels like Django and, just as important, won’t change much or risk becoming unmaintained over the next decade.
The other problem is that some apps provide Django Ninja views while others use Rest Framework, and there’s still one that has a Tastypie dependency. Unifying error outputs, etc is an exercise left to the reader.
One official, even simple, REST package would go a long way towards making the lives of many better.
Async support. I’d like to stop writing, testing, and maintaining what essentially copy’n’pasted sync/async code and a host of other reasons.
I’d like to stop having to re-write my REST APIs every time a third-party package goes into hibernation. And, I personally believe that Django should be an async-first (not async-only) framework.
Do I think the the situation terminal? No. Why would I be talking about Django 2035 if I thought it was? I have two low-grade fever tier issues that I’ve been dealing with for 20 and 10 years respectively. A lot of developers are facing these same issues. Those are the batteries on my wish list for 2035.
If there’s anything I can do help (money, time), I’m happy to help.
If the answer to “Could Django become an async-first (not async-only) framework?” is “No.” That would be good to know.
Maybe I’m the odd one out, I’m comfortable with that, but I disagree about the async complexity. I’ve been using async for years and I’ve never encountered anything that turned out to be more difficult to debug than its sync counterpart. Maybe I’ve been lucky.
My experience has been that sync-first with an async bolt-on is more complicated than the reverse.
You should definitely sponsor the DSF if you’re not doing that already.
Other than that, folks are already thinking and working on these things. You’re welcome to join that effort. The arc of history is long. We’ll have to see how it evolves.
True - but not relevent to my point. The question really is, does this database or cache usage have an adverse effect on my system? (And, given the amount of cacheing that PostgreSQL does, the amount of real I/O being performed in a read-heavy environment is a lot smaller than the number of queries being issued.)
If I have a chunk of code that performs lengthy CPU-bound operations, that becomes the operational constraint in the view. If that is running in the same thread as other views, it has a direct adverse effect on those other views.
Working in a purely sync mode, I don’t need to worry about this.
If I have multiple processes handling views, then one such process does not necessarily affect the others. (Yes, too many of them will saturate the CPU, but that situation - if it were to occur regularly - can be remedied by scaling horizontally.)
Again, I am not saying that async doesn’t have value. What I deny is the assertion that “sync Django” is “obsolete”, or that a sufficient percentage of Django users would find benefit by making Django async-first to make it worth the churn.
If you can make an async-first Django without materially affecting the performance of sync-Django, great! I’m all for it.
And yes, there are many areas where significant improvements to existing async support is possible.
My only request is that sync-Django doesn’t suffer as a result. I believe (quite strongly) that would be a huge step backwards.
I’d wager that there are more IO-bound than CPU-bound workloads running on top of Django. The only bit in my projects that are even the least bit CPU-bound are the JWT issue/refresh views. Anything that takes more that a few mils is dumped onto Celery with responses smuggled back to the user through a websocket.
But everyone’s workload is different.
Async Django is more relevant today than ever. I’ll bow of the conversation with +1 for going even further with the async support. No, further than that. Keep going.
Considering this thread is about to celebrate its 1 year anniversary I appreciate that there’s still a lively discussion to be had! I value everyone’s contributions and thoughts, there’s a lot to think about here. @michaelurban your generosity inspired me, I just matched your donation.
I think I can summarize the discussion to now as (no particular order):
Backwards compatibility is a key pillar of Django’s feature set
Django is a “big tent” framework where lots of applications are, and should be, possible
Synchronous Django is here to stay (see point 1)
We should keep investing in asynchronous Django
I think the answer to the question posed by the thread title is clear: yes, async-capable Django is absolutely still relevant.
So then it becomes a question of where to apply the available energy and I think I agree with Carlton:
The async ORM API is just a thin veneer over the synchronous ORM, and async database backends now exist. I think we should work on bridging that gap make the entire stack asynchronous (where it needs to be). I think we’re making slow and steady (though I’m not sure the word “glacial” applies :P) progress on that goal. After PR18408 there’s more work to be done to move from a DB connection to the ORM using that connection, but slow and steady is the Django way.
So beyond the ORM, what are components of Django that are in need of async interfaces/implementations? The DEP contemplates caching, forms, email, and templates as areas that could use asyncification but is that the right list?
)