Performance¶

jero is built for speed, but the only honest way to talk about speed is with numbers and a clear account of how they were produced. This page is that account.

The short version: across four workloads benchmarked side by side against seven other frameworks — Python (Litestar, FastAPI, Blacksheep, Robyn, Flask), Go (Gin), and Bun (Elysia) — jero led the Python frameworks tested in every scenario. On the pure framework hot path (a typed JSON GET) it topped this benchmark table by overall score, ahead of both the Go and the Bun service. On the I/O-bound scenarios (an upstream proxy, a database read) Go pulled well clear — there the bottleneck is the HTTP-client and database-driver ecosystem, not the framework, and that's a fight Python doesn't win today.

Read the caveats. These are favourable, constrained conditions, and a microbenchmark is not your application.

And yes — we know benchmarks are genuinely hard to do right and to do fairly. Every framework has a configuration that flatters it, every harness makes choices that nudge the numbers, and reasonable people disagree about what "fair" even means. This is one benchmark, run one way, on one machine. We've tried to be even-handed and we show exactly how it was produced below so you can judge for yourself — but please treat it as a single data point, not the last word. If you have a workload that matters to you, the only number worth trusting is the one you measure yourself.

How the numbers were produced¶

The benchmark runs each framework in isolation, one at a time. Only one framework server is up at any moment, alongside its own freshly-started dependencies — a Rust upstream service (for the proxy scenario) and a fresh Postgres (for the database scenario). Nothing else competes for the machine. This removes cross-framework contention and shared-state effects, so each number reflects that framework alone.

• Load generator: k6, a fixed virtual-user (VU) count hammering the service for a fixed duration.
• Best-of-N: every (framework, scenario) pair is run N times and the best run is kept. Repeating and taking the best beats down the ~3–4% run-to-run noise floor so the comparison reflects each framework's ceiling, not a noisy sample.
• Single worker, single core: every framework runs with one worker process; Go is pinned to GOMAXPROCS=1. This is a like-for-like, single-core comparison — not a test of how well each scales across cores.
• Identical scenarios — the same request scripts, the same selection logic, and the same scoring table for every framework.

Run configuration¶

Results¶

req/s is throughput (higher is better); mean and p99 are request latency (lower is better). vs all is an aggregate score across all three — a single "overall standing" number, normalised so jero = 1.00× in every scenario. Every framework returned 100% successful responses in every run, so that column is omitted. Frameworks are ordered by vs all within each scenario.

1 — GET /info — the pure framework path¶

Route → build a typed JSON response with a typed response header → encode. No I/O. This isolates routing and serialization, and is the closest thing to a measure of the framework's own per-request overhead.

2 — POST /movies — the authed write path (JWT)¶

Bearer/JWT auth → msgspec decode of the request body → handler → encode → 201. The realistic write path for a typed JSON API.

jero lands within ~5% of a hand-written Go service here, and led the Python frameworks tested by a wide margin.

3 — GET proxy — bound by the HTTP client¶

The service makes an outbound HTTP call to the Rust upstream and relays the response. The bottleneck is the HTTP client library, not the framework — which is why the whole Python field clusters together and Go runs away.

jero led the Python frameworks tested, but Go's mature native HTTP stack is in a different class. This gap is the ecosystem, not jero.

4 — GET /users/me — bound by the database driver¶

Reads a row from Postgres. The bottleneck is the database driver, so again the field compresses and Go's native driver leads.

jero led the Python frameworks tested again. Go was well ahead; Bun's lower p99 edged jero on aggregate score despite lower throughput and higher mean latency.

How to read this¶

• jero leads the Python frameworks tested in all four scenarios. That is the durable claim.
• On the pure framework path it beats even Go and Bun. That result is real but narrow: an in-memory JSON path plays directly to Python + msgspec's strengths and to the Rust HTTP layer underneath. It is not evidence that Python is faster than Go in general — and we are not making that claim.
• On I/O-bound paths, Go is well ahead. When the work is an outbound HTTP call or a database query, the framework is barely in the picture; the HTTP client and database driver decide it, and Go's native libraries dominate. jero stays ahead of the Python frameworks tested, which is the most it can do there.
• A benchmark is not your app. Single worker, single core, localhost, fixed payloads, best-of-N. Real workloads have more moving parts. Treat these as directional evidence that jero's per-request overhead is low — not as a promise about your production numbers.

Where jero's design earns these numbers: all type introspection happens once, at startup. The request path is dict lookup → msgspec decode → handler call → encode, and nothing is ever added to it. See the design philosophy for why that's a deliberate, non-negotiable bet.