Orisha Clears All Seven TechEmpower Test Types

There is a sentence that has been sitting over this project since the beginning: there is no reason C# should beat a compiled systems language on these workloads. Not a slogan — a thesis with a falsifiable edge. Either the machine can be made faster than the industry’s reference implementations or the premise is wrong.

It is no longer a premise.

Where we are

The official TechEmpower FrameworkBenchmarks harness — their toolset, their PostgreSQL image, their network topology, their checker — ran against Orisha, our web framework written in Koru, and printed:

| orisha
|       db            : PASS
|       json          : PASS
|       query         : PASS
|       update        : PASS
|       fortune       : PASS
|       plaintext     : PASS
|       cached-query  : PASS

Seven of seven. The submission package is built and verified end to end on both arm64 and x86.

Then we went to open the pull request, and discovered the benchmark was dead. TechEmpower sunset FrameworkBenchmarks on March 24, 2026 — the repository archived, the results site offline, the PR channel read-only. We had just finished a full verification pass against a toolset that can no longer accept the result it printed. As far as the record shows, Orisha may be the last framework ever to clear all seven of their test types — a receipt nobody else can ever get, because the counter closed.

What Orisha is

A web framework in the same class as Kestrel or Actix — written in Koru, a compiled systems language that lowers to Zig. Under the framework: an io_uring pump, a native PostgreSQL wire driver (SCRAM-SHA-256, extended query protocol, prepared statements), and a suspend/resume mechanism that parks an HTTP connection on database readiness instead of a thread. No libpq, no external web server, no framework underneath.

The way you beat uWS in this game is usually to embed uWS — the leaderboard is substantially a list of things built on top of it. Orisha beats the thing everyone else is standing on.

The numbers, with oracles attached

Every number below is what the instrument printed — the environment and measurement shape are stated because they change the meaning of every figure. Load generators were gcannon (pipelined and serial shapes) and wrk; the postgres oracle is pgbench on the same database instance.

Pipelined plaintext — the throughput headline. -c4096 -t64 -p16, 5s runs, server pinned to dedicated cores, interleaved A/B:

The serial-connection shape caps any server near its connection-count ceiling — 256 serial conns on ARM measured ~300K for both servers (uWS 288–300K, Orisha 299–360K); it measures latency, not capacity. The x86 pipelined number (6.80M, 34.28M requests in 5s) lands on top of the ARM figure — the pump is arch-portable, not tuned to one ISA.

Database routes — x86 metal (ccx43, postgres on 4 dedicated cores, pgbench oracle: 70,365 tps naive-client ceiling on this instance):

Same /db test, different environments:

Read the bottom table honestly: on weak postgres the pump extracts up to ~3× the naive-client ceiling — parked binds coalesce into shared flushes instead of each exchange waiting for its own round trip. On stronger postgres the multiple shrinks toward ~1.4× because postgres itself becomes the wall. Either way the pump is never the measured constraint on db routes.

Remaining routes, x86 metal (wrk, conn-bound shape): /json 317K req/s, /fortunes 155K req/s (real pg stream + sort + escape + HTML render per request).

Verifier: all seven test types PASS under the official TFB toolset — the receipt quoted above. The amd64 build additionally survived a sustained multi-route load run with zero crashes.

Where we benchmaxxed — because everyone does and nobody lists theirs

These are the legal optimizations every competitive entry takes; the honest part is naming them.

• Plaintext and JSON are wire-baked literals. The entire response is a precomputed byte string; the only per-request work is splicing Date into a known offset. TFB permits this for static-content tests and every competitive entry does the equivalent — but we should say it: those two handlers serialize nothing.
• The database routes are driven by handler-minted obligations. Each db handler returns a response carrying a pending obligation — one world row, n rows, n updates, the fortune stream — which answer surfaces to the connection’s exchange and the pump discharges through its suspend/resume machinery. The pump reads the debt, never a route name. Earlier drafts of this entry hardcoded the five TFB prefixes inside the pump’s dispatch; that shortcut is gone — the handlers now do the work the framework was designed for.
• What is not benchmaxxed: the pgwire codec, the SCRAM exchange, the suspend/resume machinery, the connection pool, the fortune HTML render with real sorting and escaping, the per-row SELECT+UPDATE pairs the spec requires. None of it knows this benchmark exists.

What it means

A language that didn’t exist two years ago now has a framework that passes all seven official test types, beats the industry’s reference C++ implementation on raw throughput, and sits at the database’s own ceiling on every db route. That is a debut, not a coronation — the db-bound tests are bounded by postgres for everyone, and the pipelined plaintext number now holds on both architectures (6.76M arm64, 6.80M amd64).

There is no PR to bounce — the submission channel closed with the archive. The complete, verifier-passing entry lives publicly on the fork (denstad/FrameworkBenchmarks, branch koru-orisha): a frozen artifact of a benchmark that ended before we could knock. The race continues where the field moved — HttpArena, the single-box benchmark that stepped into TFB’s place, where Orisha already runs. The submission, the verifier logs, and every number above are reproducible artifacts. Where we took shortcuts, they are listed here — not in the fine print.