Elysia vs Hono with PostgreSQL on a MacBook Air M5

This experiment compares Elysia and Hono using the same PostgreSQL database functions and Bun SQL client, without an ORM. The load generator, API and database run as separate processes on one Mac over localhost, with only one framework active at a time. These are local end-to-end results, not isolated router throughput.

Method

The baseline contains 100,000 users, 1,000,000 orders and 3,000,000 order_items, generated by a counter-based MD5 generator with seed 424242. It uses BIGSERIAL keys, foreign keys and indexes on orders(user_id), orders(user_id, created_at DESC), order_items(order_id) and users(created_at DESC, id DESC). Seeding is followed by ANALYZE; PostgreSQL is not performance-tuned.

Four workloads run separately: user 42424 lookup, latest 20 users, user 42424 with up to 20 orders, and a transaction inserting an order with three items. The selected user has 12 baseline orders. Requests reuse fixed inputs: these are hot-key, warm-cache workloads, not random production traffic.

Full uses concurrency 1, 10, 50 and 100, with five repetitions per framework: 160 trials. Frameworks run in adjacent pairs with deterministic, alternating first positions. Each trial resets/reseeds, starts the API, warms up for exactly 1,000 requests, settles for five seconds, measures for 30 seconds, stops the API and cools down for 15 seconds. Bombardier uses closed-loop HTTP/1 keep-alive with a ten-second request timeout.

Both frameworks use the same ten-connection pool, SQL, validation and JSON serialization. Elysia uses its native listen adapter; Hono uses Bun.serve. Both run in production mode without access logging or caching middleware.

All 160 trials ran on one MacBook Air (Mac17,3) — Apple M5, 10 cores, 24 GB unified memory — on AC power throughout. The exact Bun, PostgreSQL, Elysia, Hono and Bombardier versions below are read back from the machine at run time, not typed in by hand.

The model above is an Amazon affiliate link — as an Amazon Associate I earn from qualifying purchases, at no extra cost to you.

Recorded environment

Session: 2026-09-12T14-24-22-067Z-full-4423a21a
2026-09-12T14:24:22.067Z — 2026-09-12T17:03:10.238Z

ProductName:		macOS
ProductVersion:		26.6.2
BuildVersion:		25G83

Successful throughput

Five repetitions per point; all runs contribute. The line-chart vertical axes do not necessarily begin at zero; compare the exact table values.

¹ Median of per-trial statistics, not a pooled latency distribution. HTTP and transport errors: zero across every included trial. Missing percentiles are N/A.

Resource samples

Median across repetitions. CPU: one fully used core = 100%. RSS: sampled peak in MiB; PostgreSQL totals can count shared pages more than once. These measurements do not prove absence of client saturation.

Download the evidence

• Summary CSV
• Sanitized numeric raw results, all warm-ups and measurements
• Protocol, versions, source hashes and configuration

What the measurements show

No measurable difference between the two frameworks. Across all sixteen workload/concurrency cells, the largest gap between the Elysia and Hono medians is 1.75% (get-user at concurrency 100: 72,532 against 71,283 successful req/s). The median absolute gap is 0.34%, Elysia is nominally ahead in eleven of sixteen cells, and in no cell do the two frameworks’ five-repetition min–max ranges fail to overlap.

That gap is smaller than this harness’s own repeat noise. Within a single cell, five identical repetitions spread by a median of 2.94% between fastest and slowest, and by 12.67% in the worst case (create-order at concurrency 10). A difference of one or two percent therefore cannot be separated from run-to-run variation here, so this article names no winner.

What the numbers do show is where the ceiling is, and it is not the router. Sampled API CPU flattens near 113% — about 1.1 cores for the single Bun process — from concurrency 10 upward in every workload, while PostgreSQL reaches 180–430% and Bombardier itself takes 149–336% on the read workloads. All three compete for the same ten cores.

The read workloads still gain throughput from concurrency 10 to 100 (get-user 59,488 to 72,532 req/s). The write workload does not: create-order peaks at concurrency 10 with 20,459 req/s and settles slightly lower at 19,913 by concurrency 100, which is consistent with the fixed ten-connection pool plus write amplification rather than with any property of either framework.

Read this as a result about the database path on one machine, not as a framework ranking. Both routers are far from being the constraint at these rates, so the experiment mostly measures PostgreSQL, Bun’s SQL client and the shared pool.

Interpretation and limitations

Tables report the median and min–max across every repetition, not just the fastest trial. Throughput is successful 2xx responses divided by the tool’s recorded elapsed time, including final in-flight drain. Client-observed latency includes pool waiting. Reported percentile medians summarize per-trial percentiles; they are not pooled percentiles over all requests. Missing values are N/A, never substituted with RPS percentiles.

The generator, API and PostgreSQL compete for CPU and thermal headroom. Differences cannot be attributed entirely to framework overhead or generalized to a production ranking. Concurrency above ten can expose the shared pool/database limit; the client can also be the bottleneck. CPU is derived from cumulative CPU-time samples taken approximately once per second. RSS is a sampled peak, and summed PostgreSQL RSS can double-count shared pages.

Cooldown does not prove thermal steady state. This protocol does not measure room temperature or energy. It changes no power mode, CPU affinity, caches or PostgreSQL settings. AC power and a temporary caffeinate idle-sleep assertion are used. Write tables grow with throughput, so final sizes differ despite identical baseline and warm-up counts. Closed-loop traffic can hide queueing compared with a fixed arrival rate.

Only a complete Full session with no HTTP/transport errors is eligible for this article. Quick is a workflow check and is excluded. Earlier HTTP-only articles and SELECT 1 diagnostics are not directly comparable.

Reproduce and inspect the evidence

Run from the benchmark project alongside the blog repository. Execute commands drop and reseed only the project-marked benchmark_db. Keep .env private. Use the recorded Bun, PostgreSQL and Bombardier versions, frozen lockfile and attached source hashes.

bun install --frozen-lockfile
bun run typecheck
bun run test
bun run bench:run --profile quick --execute
bun run bench:run --profile full --execute
# Use the exact Full session directory printed by the runner:
bun run bench:report --session reports/runs/SESSION_ID