The recycled criticisms that sound smart, get repeated everywhere, and quietly stopped being accurate years ago.
Every few months, someone declares Django dead.
"It's too slow." "It's not async." "It doesn't scale." "Everyone's on FastAPI now."
These takes get repeated in Hacker News threads, Discord servers, and hallway conversations until they feel like common knowledge: the kind of thing you nod along to without checking.
Here's the problem: most of them stopped being true years ago, and a few were never true to begin with. Meanwhile, in 2026, Django quietly powers Instagram, Spotify, and Pinterest and serves millions of users for companies that never got the memo that it "doesn't scale."
This isn't a "Django is perfect" article. It has real, honest limitations, and I'll point to them. It's a "let's check the claims against reality" article. Because repeating an outdated criticism doesn't make you sound experienced; it makes you sound like you learned Django in 2015 and stopped paying attention.
Let's go through the six most common ones, concede what's true in each, and correct what isn't.
Myth 1: "Django Doesn't Scale"
This is the big one, and it's the easiest to debunk because the counterexamples are enormous and public. Instagram runs on Django at hundreds of millions of users. Disqus scaled Django to serve billions of comments. Spotify and Pinterest are on it. If Django "didn't scale," these companies would have been the first to find out, at the worst possible time.
The grain of truth: a naive Django app does fall over under load, but not because of Django. It falls over because of N+1 queries, missing database indexes, blocking calls in the request cycle, and no caching. Those are architecture and code problems, and they'd sink an app in any framework.
As one 2026 scaling write-up put it bluntly: scaling without measurement is superstition, and the real bottleneck is almost never the framework. It's poor query design, missing indexes, and unclear ownership.
The reality: Django is stateless by design, which is exactly what makes it scale horizontally:
- Add more Gunicorn workers or more instances behind a load balancer
- Cache expensive queries in Redis
- Push slow work to Celery
Do that, and it scales to the moon. The "doesn't scale" argument is from 2015, and it was wrong then too. The framework was never the ceiling.
Myth 2: "Django Isn't Async, So It's Slow"
This one sounds technical, which is why it spreads. And it contains a real fact wrapped around a wrong conclusion.
The grain of truth: Django came to async late (async views in 3.1, ASGI support, and async ORM operations since 4.1), and its async story is genuinely still maturing. The ORM has sync roots, and there are sharp edges. If you're building something truly async-first with heavy concurrent I/O, that friction is real. (I've written about it. It's a legitimate pain point.)
Where the logic breaks: "not async" does not mean "slow." Here's the fact the benchmarks don't advertise: most web applications are I/O-bound, not CPU-bound, and the bottleneck isn't the framework. It's your database queries, third-party API calls, and unoptimized code.
Async helps when you're I/O-bound and juggling many concurrent slow operations (external APIs, websockets, streaming). It does not magically make a normal CRUD endpoint faster. A well-architected Django app with proper caching, indexing, and query optimization will outperform a poorly written async app every single time.
Async is a tool for a specific shape of problem, not a global speed setting, and most apps don't have that shape.
Myth 3: "Django Can't Do APIs. Use FastAPI."
Django "can't do APIs" would be news to the thousands of production APIs running on Django REST Framework, which has been a mature, capable API toolkit for over a decade.
The grain of truth: for a pure, async-first, high-concurrency API microservice, FastAPI is often the better fit in 2026. It's async from the ground up, its Pydantic-based validation is lovely, and it benchmarks faster than DRF on async workloads. That's a real and fair distinction, and if that's your exact use case, reach for it.
The reality: "Django can't do APIs" and "FastAPI is better for some API workloads" are very different claims. Django does APIs extremely well, and in 2026 you're not even limited to DRF. Django Ninja brings FastAPI's exact ergonomics (type hints, Pydantic v2, auto-generated docs, native async) into Django, so you can have the modern API feel without giving up the ORM, admin, auth, and migrations.
The honest framing the community has settled on:
Django for full products and admin-heavy SaaS, FastAPI for API-first microservices. Both are correct choices, not a winner and a loser.
"Can't" is just wrong.
Myth 4: "Django Can't Do Microservices. It's a Monolith."
The grain of truth: Django encourages a monolith, and its batteries-included design is optimized for building one cohesive application. That's a real default.
Why the conclusion is wrong: "encourages a monolith" is not "can't do microservices." You can absolutely build decoupled Django services that talk over APIs and message queues, with DRF, Docker, and Celery. Django is not the obstacle; the architecture is.
And here's the part that actually matters in 2026: most applications don't need microservices in the first place. Splitting prematurely buys you network complexity, debugging pain, and operational overhead in exchange for benefits you may never use.
The guidance from people running Django at scale is to start as a modular monolith and stay one until you have a concrete reason to split:
- Teams blocked by codebase coupling
- Deployment bottlenecks
- A domain that needs radically different scaling
A well-designed modular monolith survives astonishing scale. "Django is a monolith" is a description, not an insult, and often it's describing the right choice.
Myth 5: "Batteries-Included Makes Django Bloated and Slow"
The grain of truth: Django ships a lot, and it does carry two decades of history, including some dated modules you'll never use. If your project is genuinely tiny (a single-endpoint service), Django is more than you need, and a microframework fits better.
Why it's mostly wrong: people call Django "too heavy" until they spend three days wiring up authentication, permissions, migrations, an admin interface, and CSRF protection in a lighter framework. Django gives you all of that on day one, tested and integrated.
"Batteries included is a feature, not a liability" is the take that holds up. And bloat doesn't equal slow: the modules you don't use don't run.
Django's security posture alone earns its weight:
- PBKDF2/bcrypt password hashing
- CSRF and XSS protections
- SQL-injection-safe ORM queries
- A framework that actively refuses to start with a dangerously weak config
That's not bloat; that's a mountain of correct decisions you didn't have to make or maintain yourself.
Myth 6: "Real Developers Hand-Write SQL. The ORM Is for Beginners."
The grain of truth: the ORM can generate inefficient SQL, it hides the database in ways that cause N+1 problems, and for genuinely complex analytical queries, raw SQL is sometimes the right and clearer tool. A good Django developer can read the SQL the ORM produces and drops to raw SQL when it's warranted.
Why the "for beginners" framing is backwards: the ORM isn't training wheels you outgrow. It's a productivity and safety tool that experts use deliberately. It gives you:
- Parameterized queries that prevent SQL injection by default
- Database-agnostic code
- Migrations
- Readable query composition
The mark of an experienced Django developer isn't refusing the ORM. It's using it fluently for the 95% of queries where it's clearer and safer, and knowing exactly when to reach past it for the other 5%.
Treating "I hand-write all my SQL" as a badge of seniority usually signals the opposite: someone who hasn't learned to use the ORM well, or who's reintroducing injection risks and database lock-in for no benefit. Use the right tool; the ORM is right far more often than the myth admits.
The Pattern Underneath All Six
Step back and notice something: nearly every one of these myths collapses into the same underlying truth.
The bottleneck is almost never Django. It's the architecture, the queries, and the code.
| The myth says... | What's actually happening |
|---|---|
| "Doesn't scale" | Your N+1 queries don't scale |
| "Too slow" | Your missing indexes are slow |
| "Can't do APIs/microservices" | Your design choices, not the framework |
Over and over, people blame the tool for what is, honestly, a design or discipline problem, because blaming the framework is easier than auditing your own queries. Django is a mirror here: a well-architected Django app is fast and scales enormously; a poorly-architected one falls over, exactly as a poorly-architected app in any framework would.
None of this means Django is the right choice for everything. It genuinely isn't. If you're building a high-concurrency, async-first, real-time API service, FastAPI or an async-native stack is often the better call, and Django's async maturity is a real, honest limitation. That's a legitimate reason to pick something else.
"Django is slow / dead / doesn't scale / can't do APIs" is not a legitimate reason. It's a 2015 opinion that reality stopped supporting years ago.
So the useful move in 2026 isn't to defend Django or bury it. It's to stop repeating criticisms you haven't checked, evaluate the actual workload in front of you, and pick the tool that fits it, knowing that for a huge range of real products, the boring, batteries-included, "doesn't scale" framework is quietly running some of the largest applications on the internet.
Repeating the myth is easy. Checking it is what separates an engineer from a parrot.
The 30-Second Takeaway
- "Doesn't scale": Instagram, Disqus, Pinterest, Spotify run on Django at massive scale. It's stateless and scales horizontally; what fails is N+1 queries and missing indexes, not the framework.
- "Not async, so slow": most apps are I/O-bound; async only helps with many concurrent slow I/O operations, and a well-optimized sync app beats a badly-written async one. (Django's async maturity is a real limitation for async-first workloads, though.)
- "Can't do APIs": DRF has done APIs well for a decade, and Django Ninja now offers FastAPI-style typed, async, auto-documented APIs inside Django. FastAPI is better for pure async microservices; that's a fit question, not a "can't."
- "Can't do microservices / it's a monolith": you can build Django services, but more importantly most apps shouldn't. A modular monolith survives huge scale, and premature splitting adds cost for no benefit.
- "Batteries-included = bloated/slow": unused modules don't run; the built-in auth, admin, migrations, and security (PBKDF2, CSRF, injection-safe ORM) are a feature that saves you weeks.
- "The ORM is for beginners": experts use it deliberately for safety (parameterized queries) and speed of development, and drop to raw SQL only for the rare query that needs it.
The through-line: the bottleneck is almost never Django. It's your architecture and your queries.
Your Turn
Pick your tools by fit, not by folklore. Django isn't right for everything, but "it doesn't scale" hasn't been a real reason since before half the people repeating it started coding.
Which Django myth do you hear most often? Or is there one on this list you think is actually still true? Tell me in the comments 👇
If this was useful, follow me here for more stories from the backend trenches, and subscribe to The Backend Tech Lead on Substack for weekly blueprints.
Top comments (0)