FastAPI vs Starlette: 2026 Performance & Memory Benchmark

FastAPI vs Starlette is often presented as a simple speed contest: Starlette wins the microbenchmark, FastAPI wins developer productivity. That answer is incomplete. In a fair FastAPI vs Starlette benchmark, Starlette usually has the lower runtime overhead, but the gap depends heavily on whether both applications perform the same validation, dependency resolution, serialization, and I/O work.

Key Takeaways

• Starlette leads minimal workloads: In a reported 2026 benchmark, Starlette reached 129,899 requests per second versus FastAPI’s 101,178 on compressed JSON at 4,096 connections.
• FastAPI’s cost is concentrated in the API layer: Pydantic validation, dependency injection, parameter parsing, response serialization, and schema metadata add work on top of Starlette’s ASGI foundation.
• Choose by capability cost, not throughput alone: Use Starlette when low-level ASGI control is the product; use FastAPI when rebuilding validation, OpenAPI, dependency injection, and error handling would cost more than the measured overhead.

FastAPI vs Starlette benchmark results

FastAPI and Starlette don't represent two unrelated HTTP stacks. The practical architecture looks like this:

Uvicorn or another ASGI server
        ↓
Starlette routing, middleware, requests, responses
        ↓
FastAPI endpoint processing
        ↓
Pydantic validation, dependency injection,
serialization, and OpenAPI generation

Starlette supplies the lower-level ASGI machinery: routing, middleware, WebSockets, lifespan events, streaming, background tasks, static files, sessions, CORS, and response classes. FastAPI builds an opinionated API-development layer on top of it.

That distinction matters because a Starlette route that returns a prebuilt JSONResponse isn't doing the same work as a FastAPI endpoint that parses a nested request model, resolves an authentication dependency, validates fields, filters a response model, and formats errors.

The following figures come from a reported HttpArena comparison using Starlette 1.6, Uvicorn with uvloop, one worker per core, and a 64-core/128-thread AMD Threadripper PRO 3995WX. Throughput was the best of three runs; latency, CPU, and memory came from the selected run.

The compressed-JSON result is the attention-grabber. Starlette delivered about 28.4% more throughput, while FastAPI's reported average latency was roughly 9.3 times higher. The p99 difference was even more dramatic: 8.96 milliseconds versus 537.40 milliseconds.

That doesn't mean FastAPI adds 528 milliseconds to every request. Tail latency is sensitive to saturation, queueing, worker scheduling, payload shape, and benchmark configuration. An unusually large p99 gap should prompt a repeat test, not a reflexive migration.

The database test gives a more useful production perspective. Starlette's throughput advantage fell to about 16.9%, and average latency was only 1.23 milliseconds apart. Yet p99 remained sharply different in that run. External I/O can hide framework overhead in averages while scheduling and application-layer work still affect the slowest requests.

FastAPI vs Starlette memory usage

Memory results showed a similar direction:

These are aggregate benchmark figures under a highly parallel deployment. They aren't a clean answer to “How much RAM does FastAPI use per worker?”

The totals include worker processes, connection state, socket buffers, compression, TLS, queues, thread pools, ASGI server overhead, and application objects. A 64-core deployment with one worker per core magnifies every per-process difference.

For capacity planning, measure at least three quantities separately:

• RSS per worker at idle
• RSS per worker under representative concurrency
• Total container or host memory at the intended worker count

A useful internal test might look like this:

uvicorn app.main:app \
  --workers 4 \
  --loop uvloop \
  --http httptools \
  --host 0.0.0.0 \
  --port 8000

Run the same payloads, worker count, CPU limits, compression settings, and connection levels against both applications. Record p50, p95, p99, requests per second, CPU utilization, RSS, startup time, and errors.

Where FastAPI’s overhead comes from

FastAPI's performance cost isn't one monolithic penalty. It comes from several useful features that execute around the endpoint.

For an ordinary typed API request, FastAPI may:

1. Inspect the endpoint signature.
2. Resolve a dependency graph.
3. Extract path, query, header, cookie, form, and body values.
4. Validate those values with Pydantic.
5. Construct structured validation errors when input is invalid.
6. Serialize the return value through a response model.
7. Apply response filtering and field conversion.

Most of this work is small for a simple route. It becomes more visible with deeply nested models, large payloads, multiple dependencies, and high concurrency.

OpenAPI generation is different. It is mainly a startup and schema-building concern, not a documentation operation on every request. Teams sometimes attribute all FastAPI overhead to OpenAPI, but runtime latency is more directly affected by request parsing, dependency resolution, validation, and response serialization.

The fair Starlette comparison is therefore not:

# Starlette: fixed response
return JSONResponse({"status": "ok"})

against:

# FastAPI: validation, dependencies, and response modeling
@app.post("/orders", response_model=OrderResponse)
async def create_order(
    order: OrderCreate,
    user: User = Depends(current_user),
):
    ...

A like-for-like Starlette implementation may need Pydantic or another validation library, manual parameter extraction, authentication plumbing, response serialization, standardized errors, schema generation, and documentation.

Once those features are added, the raw framework gap may shrink. You also have to maintain the code that FastAPI provided out of the box.

There is a similar trap with synchronous work. Both frameworks can send blocking functions to a thread pool. Starlette's documented AnyIO thread-pool behavior uses a default capacity of 40 tokens. Raising that limit can improve throughput for some blocking workloads, but it also increases memory pressure and scheduling contention.

Changing this:

def read_from_legacy_client():
    return client.fetch()

to this:

async def read_from_legacy_client():
    return client.fetch()

doesn't make the client asynchronous. The blocking call is still blocking. Benchmark synchronous endpoints, truly asynchronous endpoints, and thread-pool saturation as separate cases.

Should you use Starlette instead of FastAPI?

Starlette is a strong choice when the service is primarily a gateway, proxy, protocol adapter, streaming service, or WebSocket application. It gives you a small, explicit ASGI layer without requiring FastAPI's endpoint conventions.

It also makes sense when you already have validation and serialization infrastructure, or when your team needs exact control over request handling and the application lifecycle. For a specialized service with a narrow contract, that control can be more valuable than automatic documentation.

FastAPI is usually the better choice for conventional typed HTTP APIs. Its request models, response models, dependency injection, validation errors, OpenAPI output, Swagger UI, and ReDoc integration remove a large amount of repetitive code.

The right comparison includes engineering hours. If a Starlette migration saves 15% CPU but requires several weeks to reproduce authentication dependencies, validation behavior, schemas, and error contracts, the infrastructure savings may not pay for the migration.

A practical decision table:

This doesn't need to be an all-or-nothing architecture. FastAPI uses Starlette components underneath, so a FastAPI service can still use Starlette responses, middleware, WebSockets, streaming, mounted applications, and custom ASGI behavior.

A hybrid deployment is often cleaner than rewriting a whole API. Keep typed REST endpoints in FastAPI, isolate a high-connection WebSocket gateway in Starlette, and give CPU-heavy jobs their own worker model.

Before migrating, benchmark the endpoint that actually hurts. Use the production payload, real authentication, the same database query, identical compression and TLS settings, and the intended worker count. Test enough concurrency to expose queueing, then inspect p95 and p99 rather than relying on average latency.

The short rule is simple:

• If the API contract is the hard part, choose FastAPI.
• If ASGI control and minimal runtime are the hard part, choose Starlette.
• If p99 latency is the problem, benchmark equivalent behavior before changing frameworks.
• If memory is the constraint, measure per-worker RSS and total deployment memory separately.
• If Starlette requires rebuilding FastAPI's core conveniences, count that maintenance cost as part of the benchmark.

Frequently Asked Questions

Q: Is Starlette faster than FastAPI in production?

Usually, Starlette is faster for minimal routes because it performs less request-processing work. In production, the difference depends on validation, serialization, dependencies, database time, payload size, worker count, and concurrency; equivalent workloads matter more than framework labels.

Q: What is FastAPI’s p99 latency overhead?

There is no universal fixed number. In one 2026 compressed-JSON benchmark, FastAPI reported 537.40 ms p99 versus Starlette’s 8.96 ms at 4,096 connections, while an async-database test reported 296.70 ms versus 79.90 ms. Those figures are workload- and hardware-specific, so reproduce them with your own API contract.

Q: Does FastAPI use more memory than Starlette?

The reported benchmark did: FastAPI used roughly 1.4 to 1.5 GiB more aggregate memory across the tested deployments. That difference includes workers and connection state, so measure RSS per worker under your intended deployment rather than treating it as a universal FastAPI memory requirement.

Q: Should I use Starlette instead of FastAPI for a microservice?

Use Starlette when the service needs low-level ASGI control, streaming, WebSockets, or an already established validation and schema system. Use FastAPI when the microservice is a typed business API and automatic validation, OpenAPI, dependency injection, and consistent errors are worth more than the framework overhead.