#Performance benchmarks

These benchmarks help you choose a Vext HTTP adapter. They keep the Vext application fixed and compare the five supported adapters under the same light Normal workload. They are an input to adapter selection—not a substitute for load-testing your application with its real middleware, authentication, logging, database access, and deployment topology.

#At a glance

• This is an adapter comparison, not a cross-framework league table. Each row runs the same Vext routes, Normal bootstrap, handler mode, HTTP contract, middleware fixture, and load protocol; only the adapter changes.
• Native has the highest throughput in this host and workload. That is a local observation, not a claim that it is universally best.
• Fastify and Koa are the next fastest adapters in this sample; Hono and Express trade throughput for their own programming and ecosystem choices. Use the detailed CV and latency data before treating small differences as meaningful.
• Choose for integration and migration needs first, then reproduce with your workload. Native is the dependency-light default. Select Fastify, Express, Koa, or Hono when their ecosystem is the better fit.

Scope: This page compares the cost of the same Vext Normal application through different Vext adapters. The Fastify, Hono, Express, and Koa columns are not standalone/raw-framework results and do not represent performance under each framework's recommended production configuration. Make production decisions from benchmarks of your application, real middleware, and deployment configuration.

#Current results

This formal run was recorded at 2026-08-15T00:07:37.413Z from clean Vext source main@772d3eab9f3826a55526deaf2ad6b1c128bda446 (Vext 1.0.1; Node.js v20.20.2). Every value is the median requests per second from 7 rounds; higher is better for that scenario.

All 20 adapter/scenario measurements completed with zero errors, timeouts, and non-2xx responses. Per-scenario CV ranged from 0.2%–1.4%. The full per-round sample, P50/P99, exact versions, provenance, and route-lifecycle telemetry appear below on this page.

#Why this comparison

The user-facing choice is which Vext adapter to use, so every target runs the same Vext Normal application. The routes, defineRoutes() loading, route matching, request/response objects, middleware fixture, handler mode, response contract, process priority, and Autocannon protocol are fixed. Only the adapter changes.

The fixture deliberately turns off optional request features that these GET scenarios do not use: access logging, generated request IDs, CORS, rate limiting, response wrapping, body parsing, request context, session, CSRF, security headers, frontend rendering, and application logging. It retains the Normal bootstrap and route lifecycle. This makes the comparison focused and repeatable; it is not an all-features production or database/I/O benchmark.

#Why not publish “production-stack” or “bare-path” rankings?

Production load tests are essential before release, but authentication, logging, security, middleware, data and external I/O, deployment topology, hardware, and business complexity all vary. Put those results in one cross-framework RPS table and you measure the full application stack; you cannot reliably attribute the result to the framework or adapter.

At the other extreme, bare paths or the shortest HTTP path are useful maintainer diagnostics, but they omit the Normal bootstrap, route lifecycle, request/response adaptation, and middleware integration that Vext users actually select. They should not rank user-facing adapter choices.

This page fixes the same Vext Normal application and load protocol, then changes only the adapter. It measures the Vext adapter integration-path cost under a fixed, reproducible workload, not the independent performance of Fastify, Hono, Express, or Koa. Production decisions should still use load tests of your real application.

#Choosing an adapter

See the Adapter guide for installation and configuration details.

#Methodology

Before a formal run, the runner checks these dependencies against npm latest for that date. It refuses citable output when versions or source identity drift, or when any response is non-2xx, a connection fails or times out, a result is missing, or the CV gate fails. Targets are interleaved by round to reduce time drift that would otherwise consistently favor one implementation.

#Full formal sample

This complete formal sample is generated from the same artifact as the current-result summary above. It remains on this page so the conclusion, method, and every measurement can be reviewed together.

#Run identity

#Scenarios

#Every measured sample

#Normal route-lifecycle telemetry

#Exact environment and versions

#Reproduce the results

Install the lockfile and confirm that the benchmark dependencies still match npm latest:

npm ci
npm run verify:benchmark-deps

Run the public adapter comparison with the same protocol used on this page:

node --expose-gc --max-old-space-size=512 test/benchmark/run-adapter-matrix.mjs --formal --scenario all --duration 10 --connections 50 --pipelining 10 --warmup 5 --rounds 7 --max-cv 20 --process-priority 0 --handler-mode sync

This sample uses synchronous handlers. If your platform or permissions require a different priority, choose an available value and treat the result as a new environment baseline rather than comparing absolute numbers with this page.

The runner uses the local Autocannon programmatic API and starts and stops its targets automatically. This page includes every sample, P50/P99, exact versions, provenance, and route-lifecycle telemetry. See the benchmark README for all runner options and artifact merge rules.

#Test your application

A framework microbenchmark answers only “what does the core HTTP path cost?” Before production, run a workload that includes at least:

1. your authentication, logging, response wrapping, and middleware;
2. real or controlled substitutes for databases, caches, and external APIs;
3. warmup, multiple rounds, throughput, P95/P99 latency, error rate, and resource use;
4. the production Node.js version, process count, container limits, and reverse proxy.

#Limitations

• The current results come from one Windows host; they do not represent Linux, containers, or cloud platforms.
• These are small HTTP microbenchmarks. They do not measure developer experience, plugin quality, maintainability, or complete business latency.
• Do not combine absolute values from different dates, machines, dependency versions, handler modes, or load protocols into one ranking.
• The table compares Vext adapters only. Raw and shortest-path diagnostics are maintained separately and are not user-facing adapter rankings.

#Related links

• Benchmark reproduction guide
• Adapter selection and configuration
• Production deployment
• Configuration reference