Compared with familiar baselines
For minimal HTTP routing, Akan's pure HTTP path sits close to Bun-native minimal frameworks such as ElysiaJS, raw Bun.serve, and Hono. That is the important baseline: Akan is not paying a large runtime penalty before its higher-level API features are used.
ElysiaJS (Bun, minimal REST ping)133,564 RPS, p99 0.739ms
raw Bun.serve (Bun, minimal REST ping)129,970 RPS, p99 0.745ms
Hono (Bun, minimal REST ping)111,259 RPS, p99 0.843ms
Fastify (Node, minimal REST ping)83,034 RPS, p99 1.111ms
Akan Pure HTTP (Bun, runtime fast path)119,571 RPS, p99 0.812ms
Akan Signal API (Bun, Signal lifecycle)33,845 RPS, p99 2.958ms
Akan Signal API is noticeably lower than router-only frameworks because it is not measuring the same amount of work. Minimal router benchmarks usually handle a request and return a response. Signal API includes Akan's API lifecycle, middleware and guard points, request argument handling, response shaping, and the gateway-to-worker path used for load balancing. If the same features are added as middleware or plugins to a minimal router, those frameworks also pay additional overhead.
That makes 33,845 RPS with p99 under 3ms a more useful application-facing number than a bare ping result. It tells us that Akan's higher-level API path still has enough room for typical no-DB endpoints.
For document list APIs, raw bun:sqlite is the storage ceiling: it only asks how fast SQLite can return rows. Akan DB List does more work on purpose. It applies the document API shape, sorting, pagination, light projection, document materialization, response serialization, and Signal response handling on top of SQLite.
That overhead is acceptable because the measured path is closer to what a real list endpoint needs. At 5,268 RPS and p99 14.957ms, it clears the current list API SLO, so the framework cost is visible but still within a practical range.
For WebSocket fan-out, the comparison is intentionally against raw Bun rather than a higher-level realtime framework. The goal is not to claim that Akan is faster than raw WebSocket code. The useful question is whether Akan's pubsub path stays within a practical overhead range while preserving the same application model used by Signal APIs.
In the 1,000-subscriber fan-out run, raw Bun delivered about 49,983 messages/sec with p99 around 8ms. Akan delivered 50,000 messages/sec through /api/ws pubsub with p99 at 11ms, zero dropped messages, and zero connection errors. That is a small latency premium for running through the framework pubsub path.
A 5,000-subscriber local stress run also delivered 49,917 messages/sec with 0% drop and p99 47ms, but it produced 3,362 connection errors and a child health-timeout during the run. I treat that as a local stress signal rather than a clean headline benchmark.
