Django vs Flask vs FastAPI: Python's Web Framework Showdown

Python has three web frameworks that matter: Django, Flask, and FastAPI. Everything else is either niche, dead, or a wrapper around one of these three.

I've shipped production code with all of them. Here's what I actually think.

Django: The Monolith That Works

Django gives you everything out of the box. ORM, admin panel, authentication, migrations, form handling, templating, CSRF protection, session management. You pip install django, run startproject, and you've got a working app with half your infrastructure decisions already made.

That's its superpower and its trade-off. You get speed of development in exchange for doing things Django's way.

A basic API view in Django (using Django REST Framework, because raw Django views for APIs is pain):

# views.py
from rest_framework.decorators import api_view
from rest_framework.response import Response
from .models import Book
from .serializers import BookSerializer

@api_view(['GET'])
def list_books(request):
    books = Book.objects.all()
    serializer = BookSerializer(books, many=True)
    return Response(serializer.data)

Django's ORM is genuinely good. Migrations that just work. An admin panel you get for free that non-technical team members can actually use. For content-heavy sites, e-commerce platforms, internal tools, and anything with complex data models and user auth, Django saves you weeks.

The downside: Django is opinionated. Want to swap out the ORM for SQLAlchemy? You can, but you're fighting the framework. Want async? Django added it in 4.1, but the ecosystem hasn't fully caught up. Many middleware and third-party packages still block.

Pick Django when: you're building a full web application (not just an API), you need admin panels, you have complex models with relationships, or your team already knows it.

Flask: The Blank Canvas

Flask is a microframework. It gives you routing, request/response handling, and templating with Jinja2. Everything else is your choice.

The same endpoint in Flask:

# app.py
from flask import Flask, jsonify

app = Flask(__name__)

books = [
    {"id": 1, "title": "Dune", "author": "Frank Herbert"},
    {"id": 2, "title": "Neuromancer", "author": "William Gibson"},
]

@app.get("/books")
def list_books():
    return jsonify(books)

That's it. No ORM, no admin, no auth — unless you add them. Need a database? Pick SQLAlchemy, Peewee, or raw SQL. Need auth? Flask-Login or roll your own. Need an API schema? Flask-RESTful or Flask-Smorest.

This flexibility is Flask's strength. You only include what you need, and you understand every piece of your stack because you assembled it yourself. For small services, internal APIs, prototypes, and microservices, Flask's minimalism keeps things clean.

The downside: on larger projects, the "pick your own adventure" approach means every team assembles a different stack. Onboarding gets harder. You end up recreating things Django gives you for free.

Pick Flask when: you're building a small-to-medium API, a microservice, a prototype, or you want full control over every dependency.

FastAPI: The Modern Contender

FastAPI showed up in 2018 and changed the conversation. It's async-first, uses Python type hints for validation, and generates OpenAPI documentation automatically.

Same endpoint in FastAPI:

# main.py
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Book(BaseModel):
    id: int
    title: str
    author: str

books = [
    Book(id=1, title="Dune", author="Frank Herbert"),
    Book(id=2, title="Neuromancer", author="William Gibson"),
]

@app.get("/books", response_model=list[Book])
def list_books():
    return books

Hit /docs and you get interactive Swagger UI. Hit /redoc and you get ReDoc. No extra configuration. The Pydantic models handle request validation and response serialization, so you define your schema once and it's enforced everywhere.

FastAPI runs on Starlette (ASGI), so it handles async natively. Benchmarks put it significantly ahead of Django and Flask for raw request throughput — roughly on par with Node.js and Go for I/O-bound workloads.

The downside: FastAPI doesn't have Django's batteries. No built-in ORM (you'll use SQLAlchemy or Tortoise), no admin panel, no auth system. The ecosystem is growing fast but it's younger than Django's or Flask's.

Pick FastAPI when: you're building APIs (especially for mobile or SPA frontends), you care about performance, you want automatic docs, or you're doing anything with async/WebSockets.

The Honest Comparison

Feature	Django	Flask	FastAPI
Learning curve	Medium	Low	Low-Medium
Built-in ORM	Yes	No	No
Admin panel	Yes	No	No
Async support	Partial	No (use Quart)	Native
Auto API docs	No (add DRF+drf-spectacular)	No	Yes
Performance	Slowest	Middle	Fastest
Ecosystem maturity	20+ years	14+ years	8 years
Best for	Full web apps	Small APIs, microservices	Modern APIs

What I Actually See in Production

Big companies with complex web apps: Django. Instagram, Pinterest, and Disqus all run on it. When you need a full-featured web application with server-rendered pages, Django's maturity is hard to beat.

Microservices and small APIs: Flask or FastAPI. Flask if the team already knows it, FastAPI for greenfield projects. I've seen a clear trend of teams migrating Flask APIs to FastAPI for the automatic docs and type safety alone.

ML model serving: FastAPI, almost universally. The async support handles concurrent prediction requests well, and data scientists already think in Pydantic-style type annotations.

The Real Answer

If you're learning Python web development, start with Flask. It teaches you how web frameworks actually work because there's no magic hiding the HTTP request/response cycle.

Once you're comfortable, try FastAPI for your next API project. The developer experience is outstanding.

Reach for Django when you need a full application — user accounts, admin dashboards, content management, the works.

All three frameworks are covered with hands-on exercises on CodeUp, where you can build real endpoints and see the differences firsthand. There's no substitute for writing the code yourself.

The worst choice is spending a week debating frameworks instead of building something.