Been using Django in production since 2008, and so happy with my choice. Absolutely amazing being able to keep the same knowledge and workflow for my whole career so far, and still have a modern, maintained piece of software as a base. The Django Admin still makes my life better all these years later.
Props to the Fellows who are keeping these releases running on time and getting better every year. Boring software FTW!
> All models are automatically imported in the shell by default.
This is a huge usability improvement! We end up having to install shell plus in the dev environment on every project I've worked on, and it's not always available to us in production environments for debugging. Having models import automatically will be a big help.
I just started using Django a few weeks ago, but it's so much more flexible than Supabase/Firebase. I feel like I have much better control now.
I think the flexibility and agility in domain modeling is the magic sauce of ORMs like Django. The Model definition directly drives migrations and form generation (incl Admin GUI).
If you know exactly the product you are making and don't need to iterate much on the domain model, frontend-oriented frameworks like Supabase and FastAPI make sense.
Supabase was neat to get started with. The moment you need any complex backend logic it all falls apart.
A lot of things, like CRUD editing in admin, is just done for you in Django.
My other issue with Supabase is just how difficult hosting actually is. Requires a whole lot of magic/weird undocumented trickery. Vs Django which just works.
It probably really depends on what you need to build though.
In 2025, how much does it still make sense to go the Django way vs FastAPI ? Looking for well founded opinions. Not controversy.
Different purposes. If you're building a user-facing web app Django, if you're building an API-only service then FastAPI. To me the big selling point of Django is it's a batteries-included way to build a web app that works with a bunch of pre-integrated stuff including the ORM, form validation, admin site, background tasks, etc, and it is used by so many people that you are unlikely to run into any sharp edges.
I've been developing in Django with Django Rest Framework for 10+ years and just recently built my first FastAPI project, so I may be a little bit biased here.
Django takes care of a lot of common functionality for you. The biggest things for me are:
- Authentication: this includes safely handling sessions, cookies, password hashes as well as integrations with SSO providers via libraries like Social Django.
- ORM: love it or hate it, the ORM just does everything. You mostly don't need to worry or think about migrations or database support.
- Admin panel: the builtin admin panel is a great way to get a quick UI that can, in some cases, handle a pretty big swath of the UI needs for your app.
With that said, there are some things that I LOVED about FastAPI. Using pydantic for serialization is way nicer than the serializers you get from Django Rest Framework. The DRF serializers just feel slow and antiquated after using pydantic. FastAPI is also much lighter weight, and works great if you just need a quick and dirty API server.
I think that my recommendation would be to use FastAPI for microservices and Django for anything that needs to handle more than a few REST API endpoints. All the extra functionality in Django is great if you want to build a production monolith, but all those extra features are unnecessary bloat for microservices.
I agree, about the admin in particular because its something a lot of frameworks do not have.
I have used DRF in the past but I am a bit worried about it future. Discussion here: https://news.ycombinator.com/item?id=43510495
Django Ninja looks promising.
I personally choose Django as often as I can, the tooling is considerably better and the ecosystem is significantly larger. Admin is a killer app until you know exactly what you're developing. It's trivial to setup tests with pytest-django, use with a mypy via django-stubs, with django-ninja you can fastapi like routes and models based on pydantic, etc etc etc.
Because boring and stable is good. I'm not a Django fan (Rails guy here) but it's battle tested for years, there's tons of support for it, it supports server-side rendering (not just a backend for React, which god help me if I ever have to touch that POS again), and even better people know and trust it. Go look up Meteor.js and the conversation around it 10 years ago, sounded the same, but gone and never to be heard from again.
I've been doing this for nigh-on twenty years now, and my rules of thumb:
* If you're building an API, use fastapi+starlette
* If you're building a CRUD app, use Django if:
* You don't expect to need to "hyperscale" in the near future
* You need an admin UI
* Your project resembles a blog or newspaper site (i.e., a collection of articles)
* If you're not using Django, and don't need or want async Python, Flask+SQLAlchemy+alembic is still a 100% valid and effective choice.The admin. I prefer the non Django stuff for everything. Pedantic alembic sqlalchemy and so on.
But if you run something large, getting an admin panel literally for free is difficult to beat. You literally don’t need any admin functionality in your application. Django does it all for virtually free.
It's basically impossible to beat Django's breadth of packages. If you are working with a traditional app, the admin alone can give you 90% of the functionality you'll need.
Use caution here, though.
I've completed a half dozen Django upgrades at this point, and every time I ran into abandoned dependencies. The most difficult of those to deal with were Django extensions - and those were by far the most common I ran into.
In my experience, there are three ways those go:
First, the extension's functionality is no longer necessary (or helpful) because it was rolled into Django, a larger/more popular extension, Django changed enough that there's no longer a need for the extension. This is usually fairly easy to deal with. A few (~1/3?) were even updated to include migration instructions.
Next, the extension was just... abandoned. This usually happens when you have a use case you want the extension to solve, but that use case is so uncommon that there isn't a large enough audience to build a community around the extension. Then the author changes jobs, migrates their codebase, or otherwise just doesn't need to update the extension for their own needs. In this case, you get to decide if you want to remove the functionality from your project, find a replacement extension, or fork the one you're already using. Beware forking projects like this - you're committing to updating for every Django release you upgrade to in the future. I even had one case where I forked an extension only to find that the original author had passed away unexpectedly and there was in fact demand for it. I ended up managing PRs on that one for a couple of years until I was able to find and vet a couple other users to bring on board.
Finally, there are those that are dying a slow death. This could be due to lack of interest, but it seems to usually be because another extension surpassed it in terms of popularity that serves the same function.
The !fun! part is that you can't easily tell which category a dependency is going to fall into until you dig in far enough to find the project's current status. Best case, a quick trip to PyPI and I've got the dependency updated to a newer release in <10m. Worst case I end up having to trace the project's history across multiple git repositories, bug trackers, wikis, various git branches and public forks, &c while I'm walking through the exceptions raised after I've tried to use the outdated extension with a newer version of Django than it was developed against.
Last time around I ran into a group of dependencies that were all related to our implementation of a GraphQL federated subgraph. That took me a full week to untangle. By the time I was done I'd had to fork and update two libraries, got a PR merged and released on a third, and had to rip out two more. Oh, and because one of those dependencies deprecated and removed support for custom GraphQL backends for serialization, I also had to write a regex-based bash script to transform the result of the default schema generation so it would be compatible with the older version of the GraphQL router that we were using. That was a nasty enough hack that I put an intentional "time bomb" in the script so it would fail loudly if the script hadn't been updated in more than a month - then assigned that alert to the team responsible for the GraphQL router upgrade in the hopes that the (intentional) pain of having to update that file every other sprint would encourage them to prioritize that upgrade, as that service was two years out of date.
Stability, network effect. It's still a perfectly fine choice for many (most) use cases.
If you're looking for a mixture of the two, there's Django Ninja: https://django-ninja.dev
You don't have to choose between them, django-ninja gives you the same routing experience but without losing all the batteries included experience of Django.
FastAPI isn't an ORM. You use Django for the ORM.
I mostly agree - but not entirely.
Use Django if Django fits your use case. It's really as simple as that. Django is awesome: its features are well-considered, mature, and easy to learn and use. The "batteries included" philosophy means that as long as you're on their happy path, everything will go smoothly and you'll end up saving ridiculous amounts of time.
The problem starts when you try to bend Django to fit your use case, instead of vice-versa. Then all the benefits Django brings to the table turn into things you have to intentionally and carefully work around.
I've used Django ORM without using Django itself several times. It's been a while since I had that particular need, but at one point I'd built out a whole set of in-house ETL pipelines and all their supporting infrastructure using it. Most of that code was in data processing scripts that were only ever called via CLI - but because that company didn't have a ton of Python experience (it was an "enterprise" company circa 2008), and I chose Django ORM because we'd already our people already had experience with it; our reporting system was a Django project. Why require the whole team to pick up another ORM when they already knew one that would work just fine?
I've also used Django without the ORM. I really only wanted a quick web UI that wrapped an existing internal API for a dashboard. I could have used any web framework - or none at all. In fact, the whole thing _could_ have been built in CI and deployed as a static site. I used Django instead because we already had several Django projects in production - so we had documented processes in place to deploy/monitor/manage Django projects, CI templates, and an infrastructure team that we at least knew wouldn't have to get five levels of approval to deploy a "new type of application".
i remember attempting to use django for building an SPA and implementing the rest api was not at all batteries included and came with many gotchas.
That was my main reason for installing Django Extensions absolutely everywhere I could.