Why is FastAPI fast, and how do you keep it that way?

Question

Accepted Answer

FastAPI is among the fastest Python frameworks because it's built on **Starlette** (a lightweight ASGI framework) and is **async-native**, efficiently handling many concurrent I/O-bound requests. But keeping it fast requires using async correctly — the most common mistake is blocking the event loop.

## Why it's fast

```text
✓ ASGI + Starlette — a modern async foundation (vs older WSGI sync frameworks)
✓ Async-native — one process handles thousands of concurrent I/O-bound requests
  by overlapping wait times, instead of one-at-a-time
✓ Pydantic v2 — validation/serialization core is now in Rust (very fast)
✓ Minimal overhead per request
```

The async model is the key: while one request awaits a database query or API call, the server handles others — giving high throughput for I/O-bound workloads.

## The #1 way to keep it fast: don't block the event loop

```python
# ❌ blocking call inside async def → freezes the event loop, serializing ALL requests
@app.get("/bad")
async def bad():
    return requests.get(url).json()       # SYNC/blocking → kills concurrency

# ✅ use an async client and await it
@app.get("/good")
async def good():
    async with httpx.AsyncClient() as c:
        return (await c.get(url)).json()  # non-blocking

# ✅ OR use a plain def — FastAPI runs it in a thread pool (safe for blocking code)
@app.get("/also-good")
def also_good():
    return requests.get(url).json()
```

This is the single most important performance rule: a blocking call inside `async def` blocks the whole event loop, forcing requests to run one at a time. Use async libraries with `await`, or a plain `def` (run in a thread pool).

## Keeping it fast — the checklist

```text
✓ Use async DB drivers / async libraries (httpx, asyncpg) in async endpoints
✓ Run blocking code in plain def (thread pool) or via run_in_executor
✓ Avoid heavy CPU work on the event loop → offload to workers/processes
✓ Add caching (Redis) for expensive repeated work
✓ Optimize the database (fix N+1, add indexes) — often the real bottleneck
✓ Run multiple worker processes (uvicorn/gunicorn workers) to use all CPU cores
✓ Use connection pooling; paginate large results
✓ MEASURE first (profiling, load testing) — fix the actual bottleneck
```

## Why it matters

FastAPI's speed is a primary reason teams choose it, but achieving that speed in practice depends on **using async correctly** — and the most important, frequently-violated rule is **never blocking the event loop**.

Understanding *why* FastAPI is fast (async-native ASGI foundation, efficient I/O concurrency, fast Pydantic v2 core) clarifies that its performance edge applies to I/O-bound workloads handled concurrently.

Knowing how to *keep* it fast is the critical practical skill: avoiding the devastating mistake of putting blocking calls in `async def` (which serializes all requests behind a frozen event loop), using async libraries in async endpoints (or plain `def` for blocking code), offloading CPU work, caching, optimizing the database (often the real bottleneck), and running multiple workers for multiple cores.

This combination — leveraging async properly and measuring to find real bottlenecks — is what lets you realize FastAPI's performance potential, making it important senior-level knowledge for building genuinely fast, scalable APIs rather than ones that look async but perform like blocking code.