Django vs FastAPI for Side Projects

2 min read

I’ve built small projects in both Django and FastAPI over the past year. The internet has strong opinions about which is “better.” The answer, as always, depends on what you’re building.

Django: Batteries Included

Django gives you an admin panel, ORM, auth, migrations, forms, and templating out of the box. For a side project that needs a database and some CRUD, you can go from zero to deployed in an afternoon.

The ORM is the killer feature. Writing Dog.objects.filter(breed="labrador", available=True) is more readable than raw SQL, and migrations handle schema changes automatically.

FastAPI: Speed and Simplicity

FastAPI is minimal by design. It gives you routing, request validation (via Pydantic), and automatic OpenAPI docs. That’s it. You bring your own ORM, auth, and everything else.

For API-only services — a webhook handler, a data pipeline endpoint, a microservice — this is exactly right. No unused middleware, no template engine you don’t need.

@app.get("/api/dogs/{dog_id}")
async def get_dog(dog_id: int) -> Dog:
    return await dog_service.get(dog_id)

Type hints drive validation and documentation simultaneously. The feedback loop is fast.

When I Use Which

Django when:

  • The project needs an admin interface
  • There’s a relational database with complex models
  • I want auth, sessions, and forms without wiring them up manually
  • The project might grow into something real

FastAPI when:

  • It’s an API-only service
  • I need WebSocket support
  • The data model is simple or lives in an external service
  • Performance under concurrent load matters

The Honest Take

Django is boring in the best way. It has fifteen years of battle-tested patterns and a massive ecosystem. FastAPI is exciting and modern but you’ll spend time choosing and integrating libraries that Django gives you for free.

For most side projects that involve a database and a UI: Django. For everything else: FastAPI.