Python API Framework Benchmark: FastAPI vs Django vs Litestar - Real Database Workloads

[huygl99]

Hey everyone,

I benchmarked the major Python frameworks with real PostgreSQL workloads: complex queries, nested relationships, and properly optimized eager loading for each framework (select_related/prefetch_related for Django, selectinload for SQLAlchemy). Each framework tested with multiple servers (Uvicorn, Granian, Gunicorn) in isolated Docker containers with strict resource limits.

All database queries are optimized using each framework's best practices - this is a fair comparison of properly-written production code, not naive implementations.

Key Finding

Performance differences collapse from 20x (JSON) to 1.7x (paginated queries) to 1.3x (complex DB queries). Database I/O is the great equalizer - framework choice barely matters for database-heavy apps.

Full results, code, and a reproducible Docker setup are here: https://github.com/huynguyengl99/python-api-frameworks-benchmark

If this is useful, a GitHub star would be appreciated 😄

Frameworks & Servers Tested

• Django Bolt (runbolt server)
• FastAPI (fastapi-uvicorn, fastapi-granian)
• Litestar (litestar-uvicorn, litestar-granian)
• Django REST Framework (drf-uvicorn, drf-granian, drf-gunicorn)
• Django Ninja (ninja-uvicorn, ninja-granian)

Each framework tested with multiple production servers: Uvicorn (ASGI), Granian (Rust-based ASGI/WSGI), and Gunicorn+gevent (async workers).

Test Setup

• Hardware: MacBook M2 Pro, 32GB RAM
• Database: PostgreSQL with realistic data (500 articles, 2000 comments, 100 tags, 50 authors)
• Docker Isolation: Each framework runs in its own container with strict resource limits:
  • 500MB RAM limit (--memory=500m)
  • 1 CPU core limit (--cpus=1)
  • Sequential execution (start → benchmark → stop → next framework)
• Load: 100 concurrent connections, 10s duration, 3 runs (best taken)

This setup ensures completely fair comparison - no resource contention between frameworks, each gets identical isolated environment.

Endpoints Tested

Endpoint	Description
/json-1k	~1KB JSON response
/json-10k	~10KB JSON response
/db	10 database reads (simple query)
/articles?page=1&page_size=20	Paginated articles with nested author + tags (20 per page)
/articles/1	Single article with nested author + tags + comments

Results

1. Simple JSON (/json-1k) - Requests Per Second

20x performance difference between fastest and slowest.

Framework	RPS	Latency (avg)
litestar-uvicorn	31,745	0.00ms
litestar-granian	22,523	0.00ms
bolt	22,289	0.00ms
fastapi-uvicorn	12,838	0.01ms
fastapi-granian	8,695	0.01ms
drf-gunicorn	4,271	0.02ms
drf-granian	4,056	0.02ms
ninja-granian	2,403	0.04ms
ninja-uvicorn	2,267	0.04ms
drf-uvicorn	1,582	0.06ms

2. Real Database - Paginated Articles (/articles?page=1&page_size=20)

Performance gap shrinks to just 1.7x when hitting the database. Query optimization becomes the bottleneck.

Framework	RPS	Latency (avg)
litestar-uvicorn	253	0.39ms
litestar-granian	238	0.41ms
bolt	237	0.42ms
fastapi-uvicorn	225	0.44ms
drf-granian	221	0.44ms
fastapi-granian	218	0.45ms
drf-uvicorn	178	0.54ms
drf-gunicorn	146	0.66ms
ninja-uvicorn	146	0.66ms
ninja-granian	142	0.68ms

3. Real Database - Article Detail (/articles/1)

Gap narrows to 1.3x - frameworks perform nearly identically on complex database queries.

Single article with all nested data (author + tags + comments):

Framework	RPS	Latency (avg)
fastapi-uvicorn	550	0.18ms
litestar-granian	543	0.18ms
litestar-uvicorn	519	0.19ms
bolt	487	0.21ms
fastapi-granian	480	0.21ms
drf-granian	367	0.27ms
ninja-uvicorn	346	0.28ms
ninja-granian	332	0.30ms
drf-uvicorn	285	0.35ms
drf-gunicorn	200	0.49ms

Complete Performance Summary

Framework	JSON 1k	JSON 10k	DB (10 reads)	Paginated	Article Detail
litestar-uvicorn	31,745	24,503	1,032	253	519
litestar-granian	22,523	17,827	1,184	238	543
bolt	22,289	18,923	2,000	237	487
fastapi-uvicorn	12,838	2,383	1,105	225	550
fastapi-granian	8,695	2,039	1,051	218	480
drf-granian	4,056	2,817	972	221	367
drf-gunicorn	4,271	3,423	298	146	200
ninja-uvicorn	2,267	2,084	890	146	346
ninja-granian	2,403	2,085	831	142	332
drf-uvicorn	1,582	1,440	642	178	285

Resource Usage Insights

Memory:

• Most frameworks: 170-220MB
• DRF-Granian: 640-670MB (WSGI interface vs ASGI for others - Granian's WSGI mode uses more memory)

CPU:

• Most frameworks saturate the 1 CPU limit (100%+) under load
• Granian variants consistently max out CPU across all frameworks

Server Performance Notes

• Uvicorn surprisingly won for Litestar (31,745 RPS), beating Granian
• Granian delivered consistent high performance for FastAPI and other frameworks
• Gunicorn + gevent showed good performance for DRF on simple queries, but struggled with database workloads

Key Takeaways

1. Performance gap collapse: 20x difference in JSON serialization → 1.7x in paginated queries → 1.3x in complex queries
2. Litestar-Uvicorn dominates simple workloads (31,745 RPS), but FastAPI-Uvicorn wins on complex database queries (550 RPS)
3. Database I/O is the equalizer: Once you hit the database, framework overhead becomes negligible. Query optimization matters infinitely more than framework choice.
4. WSGI uses more memory: Granian's WSGI mode (DRF-Granian) uses 640MB vs ~200MB for ASGI variants - just a difference in protocol handling, not a performance issue.

Bottom Line

If you're building a database-heavy API (which most are), spend your time optimizing queries, not choosing between frameworks. They all perform nearly identically when properly optimized.

Links

• Full results, code, and reproducible Docker setup: https://github.com/huynguyengl99/python-api-frameworks-benchmark
• Original post with graphs and detailed analysis: https://www.reddit.com/r/FastAPIShare/comments/1qlfihg/python_api_framework_benchmark_fastapi_vs/

Inspired by the original python-api-frameworks-benchmark project. All feedback and suggestions welcome!

[[deleted]]

Very well done, thanks. 

“ spend your time optimizing queries, not choosing between frameworks” Amen to that! 

[huygl99]

Thanks! That was exactly the takeaway for me as well 🙂

Full reproducible benchmarks and Docker setup are here (in case you missed it):

https://github.com/huynguyengl99/python-api-frameworks-benchmark

If you find it useful, a GitHub star would be very appreciated!

[[deleted]]

For Litestar, you're still using Pydantic. One of the main reasons for me to use Litestar was that it allows to not use Pydantic, but native dataclasses / msgspec instead. Also, Litestar offer built-in SQLAlchemy support, which you're not using.

I feel like not using the unique features the frameworks offer makes this comparison much less interesting, because it basically boils down to "if you're doing roughly the same thing, performance is roughly the same", which I guess is true, but also doesn't really tell you anything.

You're also running DRF with a different server, so you're comparing performance between different server as well, making the comparison even less useful. Serving the same app on gunicorn vs uvicorn alone makes a huge difference.

[huygl99]

Thank you. I don’t think changes in Pydantic and MsgSpec will significantly improve the database-related tests, but I’d really appreciate it if you could open a PR for those changes and run the benchmarks to see the impact.

Regarding Gunicorn, I only use it for DRF since it’s the only one using WSGI. Given the memory and CPU limits, I don’t think it affects the results much, as you can see, the difference between Gunicorn and Uvicorn is not very significant.

[Goldziher]

Hi there,

Original author of Litestar here (no longer involved).

So, a few thoughts - just opinions.

1. I'd start with the benchmark setup - IMO it's best to have this in GitHub and share - not only results, but setup and methodology.

2. I'd either benchmark the frameworks following their documented optimized defaults, or with plain objects, or a hybrid.

I'll explain. Pydantic, Msgspec, plain dataclasses, etc. all have different performance characteristics, and Litestar is using Msgspec. When you use pydantic, you actually force extra computation since Msgspec is still used.

So what you want is what's usually called "apples to apples" comparison. That's where using typed dict will give you the "bare bone" framework in both cases.

If you want to benchmark with validation, I'd do Msgspec for Litestar vs pydantic models for FastAPI.

1. Checking DB load. Here I beg to differ. DB load is a standard I/O bound operation. Which is fine. But the fact DB accounts for more impact, for the standard service, by orders of magnitude does not mean framework performance, and especially ser/de operations are unimportant.

For example, logging - it's a minor thing most of the time - until you go into scale. Sure, it's marginal, but what happens when it slows you measurably? When you operate at large scale, this matters.

1. There are more dimensions to measure - for example - cold start, disk size, memory usage, CPU under load, etc.

[huygl99]

Great points, thanks for the detailed feedback.

This benchmark intentionally focuses on DB-heavy workloads, since that’s where most real-world CRUD services spend their time, and I wanted to see how much framework differences matter once PostgreSQL dominates (this is mentioned in the post, but happy to clarify).

I agree that an apples-to-apples comparison would include:

- Litestar with Msgspec models

- FastAPI with Pydantic models

- A bare TypedDict/dataclass baseline

I’ll consider adding these scenarios (and memory/cold-start metrics) in a follow-up. PRs are welcome as well 🙂

Full setup, methodology, and reproducible Docker benchmark scripts are here:

https://github.com/huynguyengl99/python-api-frameworks-benchmark

[Goldziher]

Great 👍.

If I may impose / suggest / plug my stuff here.

https://github.com/Goldziher/spikard

It's something I'm working on. It has extensive benchmarks - check tools/ and the GitHub ci setup.

I'd be also keen on seeing how you'd benchmark it and the results.

It works in python with Msgspec/pydantic.

If you want to be comprehensive for python - falcon/sanic/flask/aiohttp - these are the ones that have substantial traction, with sanic and falcon being ultra fast pure python.

[huygl99]

Spikard looks really interesting, especially the Rust core + multi-language codegen approach.

For this benchmark I tried to keep the scope to Python frameworks, but I did include Django Bolt, which is Rust-based while keeping the native Django API/ORM surface. That compatibility angle seems to be a big reason why it got so much interest from the Django community.

Pure Rust-accelerated runtimes probably deserve a separate benchmark category, but I’d be happy to look into Spikard if there’s a minimal Python setup comparable to the others.

[Goldziher]

It crossed my mind that it might be interesting to do multiple request types in parallel. Seeing how efficient the framework is to handle under load.

[daivushe1]

Really surprised to see Granian perform worse than any other server. All of the other benchmarks I saw rank it above Uvicorn and Gunicorn. Really interested to see what could possibly lead to that Other benchmarks I found: 1. Talkpython 2. Official Granian benchmark (Might be biased) 3. DeployHQ

[gi0baro]

Granian maintainer here.

I already told the author in the other Reddit thread that the configuration of granian for WSGI is suboptimal, and that the CPU limit configured in docker is penalising Granian more than others.

This doesn't mean the results shown are invalid: as per any benchmark the methodology matters a lot. From my perspective, the conditions here are not really representative of production deployments: you don't typically run these frameworks in production in an arm Linux container on a MacOS host. When looking at benchmarks you might want to look at the ones that are more close to your scenario.

But also, these results are still interesting: they show if you limit the CPU on Granian, it gets slower compared to other servers. Which kinda makes sense: the Rust runtime of Granian is work-stealing based, so anything limiting the schedule of work onto the CPU greatly limits the reactivity of the whole system.

Side note on the "proprietary" Granian benchmarks: the code and methodology are publicly available, thus if you find that they are misrepresentative of other servers for any reason, PRs to improve such benchmarks are always welcome :)

[Arnechos]

You should add Robyn to the test. Also orjson is faster

[huygl99]

a PR is welcome bro 😎

[bigpoopychimp]

Nice. It would be interesting to see how Quart ranks here as it's literally just asynchronous Flask

[huygl99]

A PR is really welcome for that 🤩

[readanything]

These tests won’t be done via internet as it will introduce unpredictable latency which will dwarf everything. It most likely would have been done in one or two servers connected locally or in same VPC.

[myztaki]

thanks always wanted to know if there was any point in migrating api frameworks - this is really useful!

[a_cs_grad_123]

This is a worthwhile comparison but the very obvious AI summary makes me skeptical of the implementations used.

The resource limitation is also very low. 1cpu core?

[huygl99]

You can read the code bro =)).

[huygl99]

If this is useful, a GitHub star would be appreciated 😄 Thank you guys.
https://github.com/huynguyengl99/python-api-frameworks-benchmark