+64.6…+81.5% req/s on DB routes: the same NestJS 12 dist/ started with bun instead of node

[Dave93]

First rung of a four-config ladder, NestJS 12.0.1 (Fastify 5.12.1) vs Elysia 2.0.0-beta.12. A is node dist/main.js, B is bun dist/main.js, same SWC-built dist/, Drizzle in both, Postgres 17 on the same box. The driver follows the runtime: postgres.js on Node, Bun SQL on Bun.

At c=100 the four DB routes moved +64.6% (GET /me), +69.9% (GET /users/:id), +78.4% (20-row list) and +81.5% (POST /orders). Idle RSS: 197 MB to 90 MB. Boot to healthy, median of 10 cold starts: 400 ms to 181 ms. GET /health didn't move, 103,273 vs 103,238 rps, inside the 1.2% noise floor measured just before.

Part of the DB gain is the driver: postgres.js under the same build on Bun costs 20.8% to 32.0% of B's throughput, so a fifth to a third of what Nest-on-Bun serves on those routes is Bun SQL.

Setup: MacBook Pro, M4 Pro, 14 cores, 48 GB; Bun 1.4.2, Node v26.3.1; bombardier on the same host; 3 × 30 s per cell, medians; run order A → B → C → D.

Two Bun snags. Nest from TS source dies in request-mapping.decorator.js: Bun compiles TS with TC39 decorators unless tsconfig sets experimentalDecorators and emitDecoratorMetadata; the built dist/ needs neither. And our runner polling ps twice a second most likely kept macOS daemons at 300–380% CPU all night; the foreign-CPU gate was already in the harness at 350%, inside that band, and raising it to 600% is what got a clean pass.

Repo, scripts, results: https://github.com/Dave93/elysia-vs-nest
Write-up, the other two rungs: https://shipkit.davrapps.dev/en/blog/elysia-2-vs-nestjs-12-what-each-layer-buys

Question for maintainers: on an empty route, is the node:http compatibility path expected to land where Node does, while Bun.serve on the same machine did 142,261? Is that 38% gap the compat layer or Fastify's own work?