Akan.js Benchmark
Run: 2026-05-30T17-11-35-780Z
Akan.js benchmark results
Akan.js 2.0.7 was measured on a MacBook M4 Pro to check the practical performance of its HTTP, Signal API, and document DB paths. The goal is simple: show how fast it is, where it sits next to familiar frameworks, and whether the results clear practical service-level targets.
Summary
- All measured Akan scenarios passed their throughput and p99 latency SLOs.
- Pure HTTP reached 119,571 RPS, placing Akan in the same practical range as Bun-native minimal router baselines.
- Signal API reached 33,845 RPS while still running Akan's API lifecycle, which is the more relevant number for application code.
- Document DB APIs stayed within the target range, including list and relation-style reads.
Performance at a glance
The bars below summarize two questions readers usually ask first: how much room each Akan path has against its SLO, and how the raw HTTP path compares with familiar framework baselines.
SLO margin by scenario
Pure HTTP
pure_http_no_db
2.4x RPS target, 6.2x p99 headroom
Signal API
signal_no_db
1.7x RPS target, 3.4x p99 headroom
DB Find
db_find_one
1.6x RPS target, 3.8x p99 headroom
DB List
db_list
1.1x RPS target, 1.3x p99 headroom
DB Relation
db_relation
10.8x RPS target, 11.5x p99 headroom
Minimal HTTP comparison
Document list vs storage ceiling
Test setup
The benchmark was run locally on a MacBook M4 Pro with Akan.js 2.0.7. Local benchmark numbers naturally depend on machine state, but this setup is useful for checking whether the framework has enough practical headroom for typical application APIs.
- Machine: MacBook M4 Pro
- Akan.js version: 2.0.7
- Akan runtime: Bun
- Akan mode: single-process local run
- Document store: SQLite
- Load profile: 50 virtual users, 10s warmup, 30s measurement
- Latest focused seed size: 300 documents
Measured surfaces
Pure HTTP
pure_http_no_db
A minimal Akan HTTP route. This shows the framework's low-level request handling speed before business API features are added.
- 119,571 RPS measured; target is at least 50,000 RPS.
- p99 latency was 0.812ms; target is 5ms or lower.
- Peak RSS was 179.39MB. Result: SLO PASS.
Signal API
signal_no_db
A normal Akan Signal API request without DB access. This is closer to the API style users write in Akan applications.
- 33,845 RPS measured; target is at least 20,000 RPS.
- p99 latency was 2.958ms; target is 10ms or lower.
- Peak RSS was 199.23MB. Result: SLO PASS.
DB Find
db_find_one
A single indexed document read through Akan's document API. This represents a common read endpoint shape.
- 16,274 RPS measured; target is at least 10,000 RPS.
- p99 latency was 5.324ms; target is 20ms or lower.
- Peak RSS was 202.44MB. Result: SLO PASS.
DB List
db_list
A paginated document list with sorting and light projection. This is a practical list API workload rather than a raw storage benchmark.
- 5,268 RPS measured; target is at least 5,000 RPS.
- p99 latency was 14.957ms; target is 20ms or lower.
- Peak RSS was 202.73MB. Result: SLO PASS.
DB Relation
db_relation
A document relation lookup using Akan's relation path and batching behavior.
- 16,149 RPS measured; target is at least 1,500 RPS.
- p99 latency was 5.228ms; target is 60ms or lower.
- Peak RSS was 202.77MB. Result: SLO PASS.
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.
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.
Is this fast enough?
For a framework that includes full-stack conventions on top of routing, these results are practical. The pure HTTP path is competitive with minimal Bun routers, the Signal API path has clear headroom above its SLO, and the document DB paths remain within their latency and throughput targets.
In short, Akan.js 2.0.7 is fast enough for typical API-heavy applications on this local benchmark: router-level performance is close to the fast Bun ecosystem, and higher-level Akan APIs still clear practical service targets.