// the find
dj-bolt/django-bolt
The fastest Python web framework, built on Django. Rust (Actix Web) HTTP server + async typed handlers + msgspec, with the full Django ORM, Admin, middleware and auth. 300k+ req/s, no gunicorn/uvicorn.
Django-Bolt replaces the WSGI/ASGI+gunicorn/uvicorn layer under Django with a Rust (Actix Web) HTTP server bridged via PyO3, keeping the Django ORM, Admin, auth and middleware intact while routing, auth checks, CORS, rate limiting and compression run outside the GIL. It's aimed at teams running Django REST Framework or Django Ninja APIs who want meaningfully lower latency without a rewrite onto FastAPI or a non-Django stack.
The architecture is a real departure, not a thin wrapper: auth/guard evaluation, routing and rate limiting happen in Rust before the GIL is taken, which is a different design than 'fast serializer, same WSGI stack'. Full Django compatibility (ORM, Admin, signals, migrate one endpoint at a time) is the actual differentiator versus other Rust/Python hybrids that demand a full rewrite. `runbolt` replaces gunicorn/uvicorn outright with SO_REUSEPORT multi-process, worker recycling and graceful shutdown built in, cutting a whole layer out of deployment. The feature surface (WebSockets, SSE, OpenAPI with multiple UIs, MCP server mounting, ModelViewSet) is unusually broad for a project this age.
The headline benchmark (300k+ req/s, beating FastAPI, Robyn, and Bun frameworks) is self-reported, single-box, loopback, JSON-payload — exactly the setup that's easiest to game and hardest to trust without independent reproduction. PyO3 means compiled native extensions per Python/platform combo, so packaging and wheel availability will bite anyone on a less common platform in a way pure-Python DRF/Ninja never does. The claim that auth/guards/routing run 'without touching the GIL' is a nontrivial FFI boundary to get right around async cancellation and exception propagation, and a young project is the place those bugs still surface. It reads as effectively a single-maintainer project (per the DeepWiki/README credit) asking teams to put a Rust HTTP layer in their production Django stack — worth weighing the bus-factor risk before depending on it for real traffic.