Benchmarks

All three run on Axum, Tokio and sqlx, and Navree and Loco both add SeaORM, so the difference is the framework. The time goes into Navree's request pipeline, not the database: on JSON, Navree used 772% of its 800% of CPU, and on one query 586% while PostgreSQL used only 329% of its 1,000%.

Reading the code at the time of the run shows where the time goes. Fixing these is the next piece of work:

1. navree-db leaves sqlx's test_before_acquire on, so every pool checkout pings PostgreSQL first: /db costs two round trips instead of one.
2. Every unit-of-work transaction adds a SELECT set_config('navree.actor', …) round trip.
3. The unit-of-work layer spawns a task for every request, /json included.
4. Process-wide locks are taken on every request: maintenance mode (a mutex and a read-write lock) and the per-IP rate limiter (one global Mutex<HashMap>).
5. The request-context layer builds metrics labels (fresh strings) even when no metrics recorder is installed, plus a request scope and a UUID request id.
6. CurrentUser finds AuthService by scanning every provider, and loads every user column, including the password hash and the two-factor secrets.
7. JSON bodies are parsed twice: into a serde_json::Value, then into the DTO.
8. Repo::insert serializes each new row for a change event even when nothing listens for change events.

What this means for an application: once a request does real database work, the gap narrows. On the authenticated list, Navree delivers 95% of Loco's throughput and 63% of hand-written Axum.

One contract

Every implementation serves the same five endpoints, defined in bench/SPEC.md, from the same seeded PostgreSQL database:

• JSON (GET /json): serialize a small object: routing and HTTP overhead only.
• Single query (GET /db): one random row by primary key.
• 20 queries (GET /queries?queries=20): 20 separate random-row queries per request.
• Auth + paginated list (GET /api/deals): jWT check, user lookup, a count and one page of 20 deals with their owners.
• Auth + validated insert (POST /api/deals): jWT check, user lookup, body validation and an INSERT … RETURNING.

The two /api/deals endpoints are what a typical API endpoint does: verify an HS256 JWT, load the user, validate the input, query or insert, and serialize the result.

A conformance gate

Before it is measured, each app must pass 170 checks in bench/tools/conformance.mjs: response shapes and types, the clamping of /queries, every way a token can be wrong, pagination order and edge cases, and validation failures. An app that fails is not benchmarked. All 15 passed.

Fairness rules

• Release builds and production settings, with no per-request access logging.
• Every app uses all 8 of its CPUs the way its framework recommends: one multi-threaded process, or one worker per CPU.
• At most 64 database connections in total, across all processes.
• Idiomatic stacks: full-stack frameworks use their own ORM, validation, auth and serializers; micro-frameworks use their most common companions.
• No caching of any kind: every request reads the database.
• The latest stable versions, pinned in lockfiles, on Debian-based images.

CPU pinning and timing

The machine has 24 logical CPUs, split so that nothing competes: the app gets 8 (0-7), PostgreSQL 10 (8-17) and the load generator, wrk, 6 (18-23). Only one app runs at a time, and its database is recreated from the same template before it starts.

Each test runs wrk with 6 threads and 256 connections: a 10-second warmup, then 3 measured runs of 15 seconds. The page reports the median run; memory and CPU are sampled while the test runs.

The drift check

A laptop can heat up and slow down over a long run, so Navree was measured first and again after every other framework, 78 minutes later. Every test landed within 3.1% of the first run, so the machine did not drift.

The load generator limits the fastest JSON results

On JSON, wrk itself was close to its 600% of CPU for Actix Web + sqlx (586%), Axum + sqlx (563%), NestJS (Fastify) (499%) and Loco (454%), so their real ceilings are higher than shown. Every other result is limited by the app or by PostgreSQL.

Some tests are bound by the database

On 20 queries, PostgreSQL used at least 60% of its 1,000% of CPU for 11 of 15 frameworks, and up to 949%; on Auth + paginated list, 11 of them. That compresses the differences between fast frameworks. Drivers that cache prepared statements (pgx in Gin, JDBC in Spring Boot) cost PostgreSQL much less per query; the leaders of 20 queries are Gin + pgx and Spring Boot + JPA.

Laravel on PHP-FPM ran out of ports

By default, Laravel under PHP-FPM opens a new PostgreSQL connection for every request. With Docker's default kernel settings, the closed connections used up the container's local ports within seconds: 100% of Single query requests failed, 57% of 20 queries requests failed, 36% of Auth + paginated list requests failed and 20% of Auth + validated insert requests failed. The figures on this page come from a rerun with net.ipv4.tcp_tw_reuse=1, the standard fix, which let the kernel reuse those ports. Production setups usually put PgBouncer in front of PostgreSQL or use persistent connections. The failed run is kept.

wrk runs on the monotonic clock

Stock wrk times requests with the wall clock. Inside the Docker VM the wall clock occasionally stepped backwards, and wrk counted phantom timeouts. The wrk used here (bench/wrk) is patched to use the monotonic clock.

These are laptop numbers

Everything ran on one laptop (Intel Core Ultra 9 275HX, Docker Desktop on WSL2), on one Docker bridge network. Absolute figures will differ on servers; the ordering is what to look at.

Measured under the working name

Navree was developed and measured under its working name, Keel. The measured code is the same; only the names changed.