The same CRUD API, built 7 times

Results

50 concurrent users, 30 seconds per run, 4 CPUs and 2 GB per app container. Every app shares one Postgres on 8 CPUs, deliberately more than any of them gets. Medians of three repetitions, never a best run.

Where Grit loses

Against Bun, two rows cannot be called. The paginated list and the mixed workload were measured four separate times. Mixed came out 0.91×, 1.21×, 1.19× and 0.91×, on both sides of even. Across seven repetitions Grit ranged from 329 to 643 req/s and Bun from 445 to 694. Any one of those numbers could be published as a result, which is exactly why none of them should be.

The reason is in the CPU column. Postgres sits at 764–825% of its 800% allowance for both sides while Grit's own container idles at 125%. Neither framework is the limit; they are both waiting on the same database, so what moves between runs is database state rather than framework speed. Those two rows are marked within noise in the table above and no winner is claimed.

The insert scenario used to be a real loss, and it is not any more. Bun was a quarter quicker at it. Postgres statement logging showed a single POST sending seven statements where Bun sent one: a transaction around an INSERT that Postgres already makes atomic, a SELECT re-reading the row just written, and an audit row written even for requests with no authenticated user. v3.134.0 fixed all three, inserts went from 2,686 to 4,959 req/s, and the scenario reversed from a 0.81× loss to a 2.23× win.

What the CPU column is for

A throughput number only means something when you know what stopped it. Where a framework's own container saturated, Laravel at 402–420% of its 400% allowance, Django at 398–408%, Next.js at 400–411%, Express at 416–434%, Bun at 399–411%. The figure is that framework's genuine ceiling on this hardware. Encore is the one exception: it never saturated anything, sitting at 142–195% with Postgres at 26–176%, so something else bounded it and its figures are a floor.

The read-heavy rows are different. On list and mixed Grit used about 120–155% while Postgres sat near 900%: the database ran out first, not the framework. Those rows are a floor, and the real gap is wider than the ratio shows. Encore.ts is the mirror image: it never saturated anything, sitting at 155–211% with Postgres at 30–200%, so something else bounded it (most likely the Drizzle / node-postgres path rather than its Rust HTTP layer) and its numbers are a floor for Encore too.

The list endpoint runs a COUNT(*) over the whole table on every request, on every framework. That is a fair comparison (they all do the same work) but at 50 concurrent users it is mostly a measurement of Postgres. For the cleanest read of framework overhead, look at show: one indexed lookup, one JSON encode, nothing else in the way.

Three bugs this found in Grit

The first draft of these numbers was much worse, and the reason was Grit's fault every time. Building a benchmark you intend to publish is an unusually good way to find out your own defaults are wrong.

How the comparison is kept fair

A benchmark is only worth publishing if the loser was given every reasonable advantage. These rules apply to every pair; the framework-specific decisions are spelled out on each guide page.

• Every framework uses its ecosystem's ORM: GORM, Eloquent, Prisma, Drizzle. Not raw SQL. Hand-written SQL on one side against an ORM on the other measures the ORM, and nobody ships the framework that way.
• Every framework runs in production shape, not its dev server: php-fpm rather than artisan serve, a cluster worker per CPU for Node, a production build for Next.js.
• Identical schemas, down to the index on deleted_at. A benchmark where one side has an index the other lacks measures the index.
• The handlers match: same default page size and cap, same searchable columns, same sortable allow-list, same {data, meta} envelope, same version bump on update.
• No auth on either side. With a token in play, part of what you measure is JWT parsing rather than the request path.
• One app runs at a time, the other stopped rather than idle, and a warm-up run is discarded so nobody pays for the other's cold start.
• The database is truncated and reloaded before every single run, and the row count is verified at 10,000 before the run is allowed to start.
• Medians of three, never the best run, and any run with a single failed request is thrown out rather than published.

Four ways this benchmark lied before it was fixed

All four are worth knowing if you build one of these yourself, because none of them announces itself. You get plausible numbers that are simply wrong. Three hurt whichever framework was being measured; the fourth hurt only Laravel, and it was published for a day before it was caught.

Reproduce it

The whole harness is in benchmarks/ in the Grit repository, compose file, seed data, k6 script and every bench app. One pair per invocation, by design: running two at once means they share a Postgres under load and both sets of numbers are worthless.

git clone https://github.com/MUKE-coder/grit && cd grit/benchmarks

# the Grit side is scaffolded, not vendored — build it yourself
grit new grit-bench --api
(cd grit-bench && grit generate resource Product \
  name:string sku:string:unique price:float stock:int active:bool)

docker compose up -d postgres

./pair.sh bun          # resets all databases, runs 3 x 4 scenarios, one app at a time
python pair-report.py bun

pair-report.py prints the app and database CPU for every row and labels which side saturated, so you can tell a real ceiling from a database limit. It refuses to report any scenario where a request failed.

Step-by-step guides

Grit vs Bun

Bun.serve with reusePort workers, Drizzle over Bun’s native SQL client

Grit vs Encore.ts

Rust HTTP runtime, compiled by Encore’s own CLI, Drizzle over its SQLDatabase

Grit vs Express

Express 5 on Node 22, one cluster worker per CPU, Prisma ORM

Grit vs Next.js

App Router route handlers, standalone production build, Prisma over Postgres

Grit vs Django

gunicorn with gevent workers, DRF-shaped views, Django ORM with connection pooling

Grit vs Laravel

nginx + php-fpm, opcache with a tracing JIT, production-only vendor, Eloquent