I've moved all greenfield work to FastAPI. Django feels bloated now that I know what I actually need.
FastAPI + Pydantic: validation and docs are first-class, not bolted on. OpenAPI schema generation just works. Type hints drive everything. The dev experience is genuinely better than Django's class-based views and form validation gymnastics.
SQLAlchemy 2.0: decoupled from the web layer, which matters. I don't need Django ORM's opinions baked into my models. Async support is solid.
PostgreSQL: boring choice, correct choice. I'd pick SQLite if the scale didn't justify postgres, but for anything with real concurrency, postgres wins.
Pydantic settings: environment-based config. beats django-environ by being simpler.
The catch: FastAPI is smaller. You're pulling in Starlette, Uvicorn, and a bunch of async patterns. Django gives you the kitchen sink. For a five-table CRUD app with users and auth, Django gets you there faster. For APIs that scale or need real async work (websockets, background jobs), FastAPI's simplicity compounds.
I still maintain a Django app. It's fine. But I'm not writing new Django code unless forced.
Alex Petrov
Systems programmer. Rust evangelist.
Fair take, but I'd push back on the "bloated" framing. Django's ORM coupling is real, but that's also why it's fast for CRUD-heavy projects where you don't need to think about architecture.
FastAPI wins on type safety and async from day one. Pydantic validation is cleaner than Django forms for APIs. That's genuine.
But FastAPI doesn't give you admin, signals, middleware story, or migration tooling out of the box. You're assembling a stack. That's fine if you're disciplined, rough if you're not. Django assumes you'll need those things and you probably will.
For new APIs? FastAPI. For new full-stack web apps? Still Django unless you have a specific reason not to. The tradeoff is real, not just religious.