Unit 01.02: Where FastAPI's speed actually comes from

FastAPI's speed is two different things, and the one that matters most is not the benchmark.

Runtime speed and developer speed

Async I/O and Rust-based validation on one side; type hints driving validation, serialisation and documentation on the other.

The code lists all four.

SOURCES = [
    ("Starlette and uvicorn underneath",  "async I/O concurrency"),
    ("Pydantic validation in Rust",       "fast parsing and validation"),
    ("type hints drive the framework",    "no separate schema to maintain"),
    ("automatic docs from those types",   "no separate docs to maintain"),
]
print(f"{'what FastAPI provides':36} what you get")
for source, effect in SOURCES:
    print(f"{source:36} {effect}")

print("""
Two of these are runtime speed and two are developer speed. The second pair is
usually the larger win: the type hints you write for the editor become the
validation, the serialisation and the documentation.

What FastAPI does not do is make your handler faster. A slow database query or
a slow model call is exactly as slow as it was.
""")

The second pair is usually the larger win. The type hints you write for your editor become the request validation, the response serialisation and the published schema - three artefacts that would otherwise drift apart.

What FastAPI does not do is make your handler faster. A slow query or a slow model call takes exactly as long as before, and that is almost always where the time goes.

The mistake this prevents

The mistake is choosing the framework on throughput benchmarks. Your bottleneck will be the database or the model API, and the difference between frameworks will be invisible next to it.

Takeaway

FastAPI gives async I/O and fast validation, and - more usefully - one declaration serving as validation, serialisation and documentation. It does not speed up your handler.

Mark complete