This is something that lots of folks seem to be getting confused about, with benchmark posts coming up on HN asking “is Django async faster than X?”.
For the API gateway use case this feature is really useful, and extends the usefulness of Django by letting it serve as a gateway for longer as your app grows and you start extracting services from the monolith.
I think part of it is the idea that in principle calling your DB is IO - but in practice your DB is fast enough that your sync view is not spending much of its time waiting on that IO.
This is a weird claim. Database calls where even moderate business logic is done at the database level can have very surprising performance characteristics and can be difficult to optimize. Taking these calls off the main thread isn’t a solution but it’s obviously a significant IO burden that doesn’t need to be shared across all of the happy paths
On my production api about 20% of each request is spent waiting on the DB. That’s with a lot of low hanging fruit remaining for optimization. YMMV. But you don’t get a speed boost by using async to talk to your DB in most common/textbook usecases. Sure, if your DB queries are complex they might take a long time in pathological cases (eg the classic accidental O(N) database query caused by not joining properly in your ORM), but the fix is usually to fix your DB queries, not add async to your API worker.
Note that simonw is a Django core dev, so when they explain what the design goals were for this feature you can be confident they are correct.
I’ll just quote it here for clarity:
> The async design for Django is predicated on the idea that the vast majority of cases are better handled by threads - but very occasionally it is useful to run an async view
This is an empirical question though, and will vary depending on workload; if you are doing something funky with long-running stored procedure calls, then you might get a win with async (make sure your DB driver is async too though, the default ones in Django aren’t last I checked). Again, my claim is just that most use cases are not like that.
For the API gateway use case this feature is really useful, and extends the usefulness of Django by letting it serve as a gateway for longer as your app grows and you start extracting services from the monolith.
I think part of it is the idea that in principle calling your DB is IO - but in practice your DB is fast enough that your sync view is not spending much of its time waiting on that IO.