borgo benchmarks

hello-json

the floor: request plumbing with almost no work attached — higher is better.

api-list

~15 kB of JSON generated per request; serialisation and body writing — higher is better.

ssr-page

a page with layout, nav, 20 rendered rows and a hydrated counter, server-rendered per request — higher is better.

static-asset

a 31,607-byte file from disk, byte-identical for every implementation — higher is better.

memory-conn

RSS of the whole process tree at rest, and the cost of holding 1000 open SSE connections — lower is better.

resident memory after boot, idle

per held connection

Not measured

A missing competitor is honest; a half-implemented one would be a lie with a table.

• fresh — stub: Deno is not installed on the machine this harness was built on, so a Fresh implementation could not be written and verified - only guessed at. It is left unimplemented on purpose: an unrun competitor is honest, a competitor we wrote blind and could not test is not. To finish it: install Deno, scaffold Fresh 2, implement routes/api/hello.ts, routes/api/items.ts, routes/api/events.ts (SSE with an immediate `: ping` flush) and routes/page.tsx per CONTRACT.md, copy the shared payload into static/, then flip status to "implemented" and fill in "implements".

Per-implementation notes

• astro (node) — Server output with the standalone Node adapter - self-hosted, like borgo. Every route sets `prerender = false`, because Astro's default would turn /page into a build-time static file and the scenario is per-request rendering. The React counter is an island (client:load), which is Astro's idiom; Astro therefore ships less client JS than the React frameworks here by design, not by accident. The shared dataset module is copied into src/lib at build time.
• borgo (bun (SSR front server) + go (API binary)) — Two processes: the Bun front server on PORT and the Go API binary on API_PORT. /api/* is proxied by the front server, which is what a deployed borgo app does - so the JSON scenarios include the proxy hop. Measured against the borgo source in this repo (go.mod replace, package.json file: link), not a published release. BUN_CONFIG_MAX_HTTP_REQUESTS is raised from Bun's default of 256 because that default caps the number of concurrent requests the front server can have in flight to the Go API - which silently ceilings concurrent SSE streams at ~255. This is disclosed rather than quietly applied: see the finding in bench/README.md. Started via the CLI entrypoint directly, exactly as the shipped Dockerfile does, rather than through `bun run start`: the latter adds a shell and two launcher processes that RSS-of-the-tree would otherwise charge to borgo, and that no production deployment runs.
• elysia (bun) — Bun-native router. Like Hono it does not claim the ssr-page scenario. Elysia's own benchmarks lean on compile-time schema specialisation that this plain implementation does not use, so treat these numbers as Elysia-as-written-here rather than Elysia-at-its-best.
• express (node) — Run on Node, which is where Express lives; running it on Bun would be a different product. ETag generation is disabled because none of the other implementations hash their bodies - leaving it on would charge Express for a feature the comparison does not ask for. Does not claim ssr-page.
• fastify (node) — Run on Node with the logger off. Fastify is fastest when given JSON response schemas so it can compile a serialiser; this implementation does not use them, because the contract's list is generated per request and the other implementations serialise generically. Fastify-with-schemas would be a fair separate entry, not a substitute for this one. Does not claim ssr-page.
• hono (bun) — A router, not a meta-framework: it does not claim the ssr-page scenario, because rendering React through Hono would be an application we wrote rather than anything Hono provides. Included as a floor - it shows what the request plumbing costs when there is almost no framework above it.
• nextjs (node) — Production build, self-hosted with `next start` on Node - the deployment borgo actually competes with, not Vercel's edge. Every route sets `dynamic = 'force-dynamic'`: left alone Next would prerender /page at build time and serve a static file, which is a different and much faster thing than server-rendering per request. Compression is off in next.config.mjs so every implementation ships identical bytes. The shared dataset module is copied into lib/ at build time because Next's bundler will not reach outside the project root. Started by invoking Next's own bin on node directly rather than through `bun x next start`: the runner charges RSS over the whole process tree, and `bun x` interposes a launcher that borgo - which is deliberately started without one, for exactly this reason - was not being charged for. Same rule for everyone or the memory table is not a comparison.