Choosing between FastAPI and Django is often presented as a contest. I find a different question more useful: which framework removes work that this product actually has?
For many mobile and frontend-backed APIs, I reach for FastAPI. These systems usually need JSON endpoints, typed contracts, external authentication, asynchronous database and API calls, and occasionally streaming. They may already use Supabase, Firebase, a separate admin application, or a database schema managed outside Python.
FastAPI fits that shape without asking the application to adopt its ORM, user model, template engine, or administration system.
@router.post('/workouts')
async def create_workout(
body: CreateWorkoutRequest,
user_id: CurrentUserId,
pool: DbPool,
) -> WorkoutResponse:
return await workout_service.create(pool, user_id, body)
The type annotations validate input, generate an OpenAPI contract, and make dependencies visible. I can choose asyncpg for PostgreSQL, Supabase for identity, and a separately deployed admin UI.
Why FastAPI fits API-first products#
FastAPI is particularly useful when:
- clients are mobile apps or a separate web frontend;
- most work waits on databases, AI providers, or other APIs;
- request and response contracts matter more than HTML rendering;
- you want to select persistence and authentication independently;
- streaming or long-lived HTTP responses are important.
Its async support is valuable only when the libraries underneath are also asynchronous. Writing async def around blocking calls does not make them non-blocking.
When Django removes more work#
Django is an excellent choice when the product wants its integrated platform:
- a model-driven ORM and migrations;
- built-in users, permissions, and sessions;
- a generated administration interface;
- server-rendered pages and forms;
- conventional CRUD over related business records.
For an internal operations product, content platform, marketplace back office, or admin-heavy business system, Django can deliver working capabilities before a custom FastAPI stack has finished assembling them.
Count the infrastructure you must own#
FastAPI's flexibility means you must make more decisions. You need conventions for project structure, database access, migrations, errors, authentication, background jobs, and observability. A small framework can still support a large system, but only when the team supplies those rules.
Django supplies more defaults. That can feel heavy when you bypass most of them, and extremely productive when you need them.
I do not choose FastAPI because Django is old or slow. I choose it when the product is a focused API and I already know which components should surround it. I choose Django when its integrated model, admin, and authentication system are features rather than unused weight.