FastAPI vs Flask vs Django in 2025

If you are starting a new project in Python, there’s three major contenders for your web framework: Django, Flask, and FastAPI.

While there are many differences between these frameworks, which one you choose can be boiled down to a few personal preference questions.

It’s actually Django vs (Flask or FastAPI)#

Django as a framework provides a lot for you. With just a little bit of code, like this:

class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField("date published")

you get database migrations that you can apply with Django’s CLI. It manages your connection to the DB and has a built-in ORM so you can just start writing DB requests in your routes, like:

latest_question_list = Question.objects.order_by("-pub_date")[:5]

It also includes an admin UI, so admins can make manual modifications to your models and users.

Flask and FastAPI, on the other hand, start you off with just the core set of features you need to get a web server up and running. The advantage (and disadvantage) here is you get to make all your own decisions. You can use a similar ORM to Django or you can use something totally different, like PugSQL. You can set up an admin UI with flask-admin, or just leave it out entirely.

This leads us to our first question:

Which of these project directories would you prefer to start with?#

or

Note the phrase “start with” - these will definitely get more complicated over time. The first one, to me, shows me that the framework has opinions. The second one, shows me that the framework values simplicity.

The first one was Django, while following the getting started guide. The second one was FastAPI (and Flask is basically identical here).

This is your first decision point, if you like the first one and you want a framework that has a lot of things already in place for you, Django is a great choice. If not, read on!

Another way of asking this question is when you are starting a project, do you prefer to use a template that’s picked a bunch of libraries for you? Or do you prefer to start from scratch and add those libraries yourself?

Flask vs FastAPI#

Flask and FastAPI scratch very similar itches. This is a valid Flask server with a single route:

from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
    return {"Hello", "World"}

And here is FastAPI:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def hello_world():
    return {"Hello", "World"}

So… just flip a coin and you are good, thanks for reading!

Ok, actually, it’s kind of challenging to provide strong guidance between the two given how much they overlap.

If the distinction between Django and (FastAPI/Flask) is that Django is more opinionated, I would say that the main distinction between FastAPI and Flask is that FastAPI has some opinions, it just doesn’t force them on you.

Flask is more of a true micro-framework, in that you can choose what you need from the very large ecosystem of libraries / plugins.

To show this in the simplest way possible, let’s look at CORS. Enabling CORS in Flask usually means pip install flask-cors and using that library. FastAPI has a built-in CORSMiddleware that you can add.

Is it that much work to pip install flask-cors? No, not really. Is it nicer to have something built in? Very, very slightly, yeah.

The same thing is true for validation libraries. FastAPI has built-in support for Pydantic, which allows you to pass in Pydantic models to your routes and have them automatically be validated:

# Define a Pydantic model for the item schema
class Item(BaseModel):
    name: str
    price: float
    quantity: int = Field(default=0, ge=0)  # optional field with validation (non-negative)

@app.post("/items", status_code=201)
async def create_item(item: Item):
    # If request JSON doesn't match Item schema, FastAPI returns a 422 error with details
    # If it passes validation, we get an Item object (with types already enforced)
    return store_in_db(item)

However, you can absolutely hook up Pydantic (or other libraries like Marshmallow) in Flask and get similar semantics to what FastAPI provides out of the box.

The features that might tip the scales for FastAPI#

While it may be trivial to set up CORS or validation in both frameworks, FastAPI does have some nice features that are more complicated to set up in Flask.

Dependency Injection / Testability#

If you are new to Dependency Injection, we have an in-depth guide here. For a quick version if it, FastAPI’s depends allows you to explicitly pass in shared logic to a route. I can have a route like this:

@app.get("/whoami")
async def who_am_i(user_id: str = Depends(user_id_from_api_key)):
    return {"user": user_id}

where important authentication logic is abstracted away behind the user_id_from_api_key dependency. This dependency can be easily re-used in any of my routes and explicitly typed.

What is user_id_from_api_key ? It’s a function that is run when the request is called and outputs some value to the route.

def user_id_from_api_key(db: Session = Depends(get_db),
                         x_api_key: Union[str, None] = Header(default=None)):
    if x_api_key is None:
        raise HTTPException(status_code=401)

    api_key = lookup_api_key(db, x_api_key)
    if api_key is None:
        raise HTTPException(status_code=401)
    return api_key.user_id

Notably, it can take in it’s own dependencies as well, like the built-in Header dependency or this get_db dependency:

# This is recommended from FastAPI's docs
# By yielding, the request continues and uses the DB
# It'll only be close when the request is finished
def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

Other than providing a very clean way to re-use logic, this also makes our application easier to test. I can override dependencies when testing, to hard-code a value for the user, without even needing to hook up a database:

app.dependency_overrides[user_id_from_api_key] = "1234"

Getting a similar setup in Flask is complicated - Flask tends to rely more on the global g value which is a request-scoped value. You can wrap your usages of g in functions and mock those functions, but again, it’s a little bit nicer when it’s built into the framework.

Interactive API Docs / Client generation#

If you run the server with the who_am_i route from the previous section, you are in for a nice surprise when you go to http://127.0.0.1:8000/docs (or whichever port you ran it locally on).

FastAPI automatically generates an OpenAPI schema from your routes. Importantly, it was also able to understand our that we are looking at the x-api-key header from the dependencies we hooked up.

Not only does this make testing easier, but it also makes generating clients of your APIs easier, as you can be confident your OpenAPI schema matches your backend.

What tips the scales for Flask?#

Flask has been around for a long time, and has been stable for a long time. Even it’s most recent major version release (3.0.0) had minor to no breaking changes, meaning you won’t have to update your code frequently as the framework “evolves.” This isn’t to say FastAPI has had a lot of breaking changes, just that Flask has a very great track record here.

They also have very detailed documentation on all the common patterns that you’ll run into when creating a production application and there’s a ton of libraries / extensions that have been built and tested with Flask.

Why didn’t you talk about performance?#

For the vast majority of projects, performance isn’t a great metric to make this decision off of. It’s just difficult to get to the scale that you would need to actually see the differences. Also, if you do, you can always scale horizontally. Large companies have been built off of all three of these frameworks, so I believe the developer experience is way more important.

Just tell me what to do!#

It’s always frustrating when a comparison article ends with “Ultimately it’s up to you!”

It is ultimately up to you, but I assume you are reading this because you want someone to give you their opinions.

I’ve used all three frameworks for different projects, and at PropelAuth we’ve built authentication libraries for all three frameworks as well.

Personally, I primarily reach for FastAPI lately because I personally prefer to try out new technologies in my projects. I like swapping out the DB layer to something new like Piccolo or SQLModel. I also really like the built in support for generating an OpenAPI schema. I don’t need to annotate things, it works natively with dependency injection, and I can use that spec to autogenerate client libraries.

I have replaced most of my usage of Flask with FastAPI as of late, even for simple tasks.

When I want to move quickly and not worry about all the little technology decisions I could make, I reach for Django. This is less often for me lately because my day job uses Rust on the backend, but I’ve built a few side projects in Django, and it is nice how quickly you can be live in production with every important feature down to database migrations.