HyperlambdaHyperlambda vs FastAPI
One claim, stated with its conditions, with the raw numbers as JSON, the ways it is unfair, and the scripts to check it yourself. It was run mostly by Claude, an AI model, under the supervision of Magic's author, on one laptop, and has not been independently replicated.
The claim
On a pooled SQLite read of ten rows at 128 connections, Hyperlambda served 3.7 times the requests per second of FastAPI on four worker processes, and 14 times FastAPI on one worker. Per CPU core the gap is 1.8 times, because Hyperlambda used about twice the cores.
Results at 128 connections
| Server | Req/s | p99 latency | Peak memory | CPU used | Req/s per core |
|---|---|---|---|---|---|
| Hyperlambda, one process | 64,664 | 5.6 ms | 309 MB | 914% | 7,075 |
| FastAPI, 4 workers | 17,686 | 77.4 ms | 311 MB | 459% | 3,853 |
| FastAPI, 1 worker | 4,564 | 83.9 ms | 63 MB | 232% | 1,967 |
The ranking is the same at 64 and 256 connections. A rerun from scratch, with fresh builds, gave 3.5 times and 13 times.
The conditions
- Workload: the first 10 rows of the Chinook
Artisttable ordered byArtistId. The script fetches the JSON from every server and aborts if any of them differs. - Connections: pooled SQLite on both sides, no authentication on either side, Magic logging at Warning.
- Load:
wrk4.2.0 with 4 threads, 3 seconds of warm-up discarded, then 10 seconds measured, on the same machine as the servers. - Machine: MacBook Pro, Apple M3 Pro, 11 cores, 18 GB, macOS 14.8.
- Software: Magic as a Release build on .NET 10.0.107, commit
ffaaac757b6702265d23a3c266f15ca35dc48618. Python 3.13.9, FastAPI 0.161.1, uvicorn 0.54.0, aiosqlite 0.22.1, uvloop and httptools, async handlers, no ORM, no middleware.
Where this does not hold
- Not per core. 3.7 times is a whole-machine figure. Per core it is 1.8 times.
- Pooling is off by default. Magic ships with
Pooling=False. With it, the same read does 4,232 requests per second, which is slower than four-worker FastAPI with per-request connections (6,245). Pooling takes Hyperlambda to 62,003. - Trivial endpoints. On an endpoint that only builds a string, FastAPI is more efficient per core (21,970 against 12,141 requests per second per core). Hyperlambda's lead appears when the request touches data.
- Worker count. Four workers was the best Python configuration we found, and more made it slower: 11 workers did 10,778 requests per second at 128 connections. We also tried 6, 8 and 10 workers, with lower throughput too, but those runs were not recorded, so only 1, 4 and 11 are published. Why more workers are slower was not investigated.
- Scope. One read of ten rows, on localhost, with no authentication, writes or joins. The load generator shares the machine with the server.
- Provenance. The measurements were made mostly by Claude, an AI model, under the supervision of Magic's author, who wrote Magic. Nothing here has been replicated independently.
Reproduce it
The scripts are in the repository under benchmarks/fastapi, and the article contains every file needed, in full: setup.sh, bench.py, app.py, requirements.txt and the three Hyperlambda endpoints. It builds Magic at the two pinned commits, installs the Chinook database through Magic's own plugin, and prints one line per measurement. Expect about 20 minutes and git, the .NET 10 SDK, Python 3.13, sqlite3, rsync, curl and wrk. Expect individual cells to move a few percent from run to run.
If your numbers disagree, please send them to me and publish them.