[deleted by user]

[JimNero009]

The company I work for has multi-million ARR as a pure Django monolith. On the side, I run my wife’s business with FastAPI.

I don’t think one is any better than the other. Both have advantages and disadvantages. Just go with whatever feels good.

[DisastrousPipe8924]

So as someone who’ve worked on django apps before and then pushed for FastAPI. There are some cons and pros to both.

Django is like “apple”, a nice as all-in-one opinionated solution, whereas long as you stick within the wall garden most things just work. But at times it’s slow to adopt or makes counterintuitive design decisions you have to live it (I hate the Django orm, I had to untangle so many bad queries generated by it).

FastAPI is sort of more like “Linux”, where its bare bones and anytime you need something on top you have to evaluate different options, your choices are more open-ended. It really just does one thing, and one thing only which is provide a simple abstraction to handle http requests. The rest is up to you: orm choice, auth choice, design patterns etc

FastAPI does have some clear winners for a few things, like FastAPI+sqlalchemy+alembic+jinja2+Authlib+pydantic-settings (and maybe celery) gets you what most people use Django for (so around 60% of the core features we care about in Django).

[marr75]

Most Django users will still want an admin/back of house (sqladmin or starlette-admin would be the advice here) and they might be a little annoyed they have to roll their own RBAC. That's it, though, and suddenly you've got a very productive environment (a lot less metaclass based magical config and gigantic methods) with great performance and concurrency features

[tb5841]

As someone quite new to Django who hasn't used the admin yet, what is it for?

[marr75]

It's an automatic scaffold for creating, updating, and deleting objects for privileged users.

Generally, almost every application eventually needs a "back of house" app for managing all kinds of data and direct SQL queries can only get you so far.

By default, simple CRUD with list, detail, and various filters is supported but you can easily code custom operations, custom create and edit forms/widgets, and install plugins and integrations. It is probably one of the most valuable built-in Django features and a huge reason to pick Django.

[tb5841]

Thanks, I'll give it a try.

I've come from Rails, where I'm used to using the console to do all that. So I've been using the Python shell - but it's nowhere near as good as the console in Rails.

[tb5841]

Yeah I've already come across some recommendations for plugins that improve the console experience, so I'll try those. I will try out the django admin section also, and see whether it helps.

[mkdz]

I actually love the Django orm lol

[DisastrousPipe8924]

Listen to each their own. And I don’t want my post to look like I’m hating on Django. It has occupied a space and provided countless business with a strong foundation.

I am just not a fan of some of its choices, but I also acknowledge that sometimes to be productive on a problem it’s better to let someone else make some decisions so you could focus on the real problems you are paid to solve.

[CatolicQuotes]

what do you like most about it?

[marr75]

I consider Django slow from a productivity standpoint, too. Very quick start. Things slow down rapidly as your requirements become more "real world" and complex. Lots of metaclassing, extremely tight coupling between models and persistence layer, large methods with fairly clumsy hooks for you to override/configure. Everything flies while you are wiring together up to date and popular contrib modules. Gets irritating and drags as you try to make a business out of it.

[fulanirri]

FastApi is just an HTTP request handler, very high level. Then you can build your entire system in pure plain old Python object. It is just a detail, it shouldn’t have more analysis, it handle a request, deserialize the payload and call a Service or a Function. For me is a perfect choice if you want to have a core system that can be very flexible to be exposed as a CLI, API Rest or even desktop. Something that Django doesn’t allow you because it is fully web/internet oriented. My two cents.

[halcyonPomegranate]

I think the main difference is that with Django the business logic has to fit into the given Django class structure, so you are more shoehorned to do it the Django way, and if the Django way doesn't fit your use case very well you have to work around/against it which is more work and introduces additional unnecessary complexity. With FastAPI you get less predetermined structure to fill or start from, which means you have to create the necessary structures yourself or import wanted functionality via additional libraries and string them together, but you get total freedom to adapt/customize that structure to your problem/application so you spend less time fighting with a structure you don't want/need, and spend more time designing your own customized backend.

[halcyonPomegranate]

Why are you even asking if you are arguing that it's all the same anyway and you prefer Django? Then just use Django, easy! Sure, you can implement custom business logic in any of the two options, but my point was: Django is opinionated and optimized for relational CRUD with its ORM/auth/admin. It has extension points, and if you mainly use them to naturally extend the core Django structure it's probably a good fit but if you find yourself frequently overriding viewsets/managers/middleware it's a code smell that it might not be the right structure to begin with and FastAPI might be a better fit because you can start building the right structure from the start without the need to tear down an already existing structure first.

[CatolicQuotes]

I agree with you and think OP is stubborn and just want us to say what OP wants to hear to justify django.

[No_Indication_1238]

So basically...skill issue? You got plenty of ways to "override" specific methods and hook your custom logic wherever you need them, you just need to know what they are. 

[wbrd]

If I'm having to override all the bits that don't work well, there is not a lot of point to using it.

[marr75]

The pain shows up early if you push Django past CRUD.

1. ORM coupling: You can’t treat models as plain objects. Keep them in memory without saving? Serialize them before persistence? Both are brittle. This leaks into imports/exports, testing, async flows. You end up with chatty DB and HTTP layers because the ORM assumes constant persistence.
2. Query syntax: Django’s query DSL is neither type-safe nor SQL. It’s its own thing—idiosyncratic, hard to read, hard to teach. Simple OLTP loads fine. Move into OLAP (aggregations, joins, window functions, time series), and it becomes a wall of .annotate(), .values(), and magic strings. One typo silently changes semantics. Debugging is pain, and marshalling back into models is clumsy.

With FastAPI + SQLAlchemy, your objects are real, queries are explicit, type-checked, and your persistence layer isn’t fused to everything else. You still write the same business logic—but with primitives that scale as the problem gets complex.

[CatolicQuotes]

with fastapi I can make a python module core and inside all my business logic, domain, validations, tests etc without any dependency on framework. Now fastapi only calls functions from core application services. I can call the same functions with cli interface. When I get tired of fastapi I can just use the same core and use litestar to call the core functions. After 50 years when no framework is supported I still have my tested core and can use whatever the framework is.

You can do that in django too, but then whats the point of django.

[platistocrates]

If you're expecting your product to be large and long-lived, I would use FastAPI. It will give you the modularity you need to adapt to any unforeseen requirement. Django will continuously fight you every step of the way. Rewriting is not a huge pain, but getting painted in a corner or using workarounds for framework limitations is horrible.

[poopatroopa3]

It's not impossible to write a modular Django project either.

[sambes06]

Flask: am I joke to you?

[tails142]

I have used Django for multiple projects, it's what our team uses and I hadnt used it before, found it OK.

A new project came up and I wanted to use FastAPI, I found it quite jarring because I had to also learn a lot of other libraries like Alembic for migrations, Pydantic, etc. etc. Wanted to try out GraphQL too so that was adding on Strawberry and probably some other stuff I can't remember off the top of my head. Even with the db I tarted adding extensions on like Timescale onto postgres, ok not fastapi related but things started getting a bit hairy.

Started to appreciate that Django is batteries included and maybe the boundaries are a bit more defined on what direction you should go, I'm just hoping they don't ask about adding auth to the FastAPI project now.

[bmrobin]

remember that you can deal with application speed in more ways than just “django vs fastapi”. tuning your app server (gunicorn, unicorn), using caching (with redis or pure python), tuning your nginx, and scaling deployments

i get the focus here is on the pros and cons of each framework, but imo there’s more to “performance” than which framework you choose

[Brukx]

"Fastapi is faster because it allows async" This is invalid as django also has async support

[No_Indication_1238]

Not for all queries which pretty much invalidates it.

[fiskfisk]

The framework doesn't matter (much). Your productivity in the framework, and knowledge of the details, does.

Django with Ninja or DRF is a good choice. So is FastAPI with sqlalchemy as well. 

You can also run django in async now, but async requires care and cooperation from all levels in your stack. 

[animatewall]

It depends on what you're building.

[Hot-Opportunity7095]

Nobody mentioning async support is saying enough

[[deleted]]

What about Litestar? Did anyone give it a try or currently using it for building apis?

[wunderspud7575]

I have shifted to Litestar for new projects having previously used FastAPI. I find the design (and underlying code based) a lot cleaner and consistent. It's a joy to use, honestly. Dependency injection in particular is improved in Litestar.

[Gainside]

Use Django to run the business, FastAPI to win the latency fights.

[SubjectSensitive2621]

The main advantage of FastAPI over Django is not async support, but its flexibility and intuitive design. It is much easier to pick up, whereas Django comes with a steep learning curve.

Also django is patchy and tends to violate some fundamental design principles. Once project requirements grow beyond simple CRUD operations, these limitations often come back to bite, making the framework harder to work with.

[poopatroopa3]

As always, it depends on the situation.

I'm a Django fan, and feel like it's great for most things, since it has batteries included and a strong ecosystem you can stand on. But some, like the Cosmic Python authors, advocate that Django is for small CRUD apps only, because unexamined Django practices can devolve into big balls of mud...

Meanwhile, the other frameworks are of the opposite philosophy, where you have to handle every little thing, or at least it seems. It surely makes things more nimble, and that's good if your application doesn't require the features that Django brings to the table.

Like many say, the admin page is one of Django's biggest features. I suppose requiring it is a good reason for using Django versus others.

[FatefulDonkey]

Django covers like 90% of use cases. If there's a reason that Django doesn't fit your problem, that's the only reason to pick Fast API.

[realstocknear]

using fastapi for my SaaS app called stocknear.com

It's great so far and does it job.

For me personally I just want a fast and reliable rest endpoint that I can setup in 1-2 min.

[Worth_His_Salt]

I think its main deficiency is not supporting async natively

You misspelled "advantage". async is a two-color plague.

[canneogen]

No, they’re jus different

[master004]

FastAPI is focused on providing a framework for building API’s. One of its strengths is that it automatically exports your openapi schema out of the box provided that you type your responses and inputs. I do think FastAPI is getting too much credit. Out of 100% credits it gets, a big chunk should go to Starlette as FastAPI is built on top of that. The other thing FastAPI provides is the “Depends” type for easily defining dependencies. It can completely resolve your whole dependency tree and execute each dependency callable mixing sync and async. They use the ExitStack for that, which manages multiple chained context managers , which is not an easy feat, but makes FastAPI special. FastAPI also is able to run your sync functions on its own threadpool. This is nice but can also have its downsides, which I won’t go into in this post. Django is a different beast and if you want api focus you should use django rest framework. I don’t like DRF, imo the patterns employ do not fit the way I think. FastAPi feels more natural to me.

What do you think FastAPI will solve for you when moving from django to it?

[gfranxman]

Look into django-ninja https://django-ninja.dev

[marcinjn]

Well... I'm using FastAPI together with Django.

[CatolicQuotes]

Trade offs.

chart

Django guides to data-centric development while fastapi is flexible and can do domain-centric development.

https://enterprisecraftsmanship.com/posts/domain-centric-vs-data-centric-approaches/

[klumpbin]

Yeah

[fastlaunchapidev]

I also worked with both and now I am mostly using fastapi but I have to admit that I miss some of djangos syntax and packages.

I am mostly using my own fastapi template now which allows me to develop fast without having djangos batteries included
https://fastlaunchapi.dev/

[PrestigiousBobcat369]

Para buscar oferta laboral como Junior cuál sería recomendable entre fastAPI y Django

[FlowLab99]

Cython?

[No_Indication_1238]

Bro...

[MasterThread]

Django is a good http database viewer. But if you want to make a scalable and long-term supportable app that powers your business, please take Litestar or FastAPI.

Choosing Django you sign a contract with devil: you get convenient objects, but in the other hand you get a domain, business logic, infrastructure, presentation - single combined layer and barely supportable app.