image
Akan.js
DocsBlog
English
image
Akan.js
DocsBlog
DocsBlog
Released under the MIT License
Official Akan.js Consulting onAkansoft
Copyright © 2026 Akan.js All rights reserved.
System managed bybassman

Akan.js Benchmark

Run: 2026-05-30T17-11-35-780Z

Akan.js benchmark results

Akan.js was measured on a MacBook M4 Pro to check the practical performance of its HTTP, Signal API, document DB, and realtime WebSocket paths. The goal is simple: show how fast it is, where it sits next to familiar baselines, 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.
  • WebSocket fan-out delivered 50k messages/sec to 1,000 local subscribers with p99 delivery latency at 11ms and no dropped messages.

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

RPS119,571 / 50,000
p990.812ms / 5ms

Signal API

signal_no_db

1.7x RPS target, 3.4x p99 headroom

RPS33,845 / 20,000
p992.958ms / 10ms

DB Find

db_find_one

1.6x RPS target, 3.8x p99 headroom

RPS16,274 / 10,000
p995.324ms / 20ms

DB List

db_list

1.1x RPS target, 1.3x p99 headroom

RPS5,268 / 5,000
p9914.957ms / 20ms

DB Relation

db_relation

10.8x RPS target, 11.5x p99 headroom

RPS16,149 / 1,500
p995.228ms / 60ms

WebSocket Fan-out

websocket_fanout

1.3x msg/s target, 4.5x p99 headroom

msg/s50,000 / 40,000
p9911ms / 50ms

Minimal HTTP comparison

ElysiaJS (Bun)133,564 RPS, p99 0.739ms
raw Bun.serve (Bun)129,970 RPS, p99 0.745ms
Hono (Bun)111,259 RPS, p99 0.843ms
Fastify (Node)83,034 RPS, p99 1.111ms
Akan Pure HTTP (Bun)119,571 RPS, p99 0.812ms
Akan Signal API (Bun)33,845 RPS, p99 2.958ms

Document list vs storage ceiling

raw bun:sqlite (storage ceiling)27,775 RPS, p99 3.42ms
Akan DB List (document + Signal path)5,268 RPS, p99 14.957ms

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.

  • 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
  • WebSocket profile: 1,000 subscribers, 1 publisher, 50 publishes/sec, 60s 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.

WebSocket Fan-out

websocket_fanout

A realtime fan-out workload: one publisher sends timestamped messages to 1,000 subscribers through Akan's /api/ws pubsub path.

  • 50,000 msg/s measured; target is at least 40,000 msg/s.
  • p99 latency was 11ms; target is 50ms or lower.
  • Peak RSS was 189.48MB. 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.

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.

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, the document DB paths remain within their latency and throughput targets, and the WebSocket pubsub path handles the 1k local fan-out target without drops.

In short, Akan is fast enough for typical API-heavy and realtime application paths on this local benchmark: router-level performance is close to the fast Bun ecosystem, higher-level Akan APIs clear practical service targets, and realtime fan-out stays in a usable overhead range.