Hono vs Express vs Fastify (and NestJS) in 2026: Real Benchmarks on Node 24, Node 26 and Bun

Hono vs Express in 2026 is a closer race than the benchmark charts you've seen suggest. On Node.js 24, Hono served 1.44× as many JSON requests per second as Express 5 in my tests, and Fastify was right next to it. But Fastify beat Hono on route parameters and POST bodies, and NestJS added 21 to 23% overhead on top of whichever engine it ran on. The biggest jump didn't come from the framework at all: moving Hono from Node to Bun gave another 1.6×.

I benchmarked seven setups (raw node:http, Hono, Express, Fastify with and without response schemas, and NestJS 12 on both its Express and Fastify adapters) across three workloads, two Node versions and Bun. Here's every number, how I got it, and which framework I'd pick for which job.

TL;DR: Hono vs Express vs Fastify, which is fastest?#

On Node, Hono and Fastify are tied for first, and both are about 1.4× faster than Express. Hono won the plain JSON test, Fastify won route parameters and POST bodies. Express 5 is the slowest of the three but still served 50,000 requests per second on two CPU cores, which is more than most APIs will ever see. On Bun, Hono pulls clearly ahead at 118,000 requests per second.

My pick: Hono for new APIs, especially anything that might run on Bun, Cloudflare Workers or another edge runtime. Fastify for Node-only services where you want schemas, plugins and the best throughput on real routes. Express when the team and middleware already exist, because it's fast enough. NestJS when the codebase is big enough that structure matters more than 20% of throughput, and then put it on the Fastify adapter.

What are Hono, Express and Fastify?#

All three are HTTP frameworks for JavaScript and TypeScript, and they come from different eras.

• Express is the 2010 original and still the default. Express 5 finally shipped native promise support in route handlers and dropped a lot of legacy API. It has the largest middleware ecosystem by far: 145 million npm downloads in the week of October 6 to 12, 2026.
• Fastify was built for speed on Node. It compiles JSON schemas into fast serializers and validators, has a strict plugin system with encapsulation, and logs with Pino by default. 15.4 million downloads that week.
• Hono is built on web standards: handlers take a Request-like context and return a Response. The same app runs on Node, Bun, Deno, Cloudflare Workers, AWS Lambda and Vercel. It's tiny and has zero dependencies. 74 million downloads that week, partly because other tools bundle it.
• NestJS isn't a fourth HTTP engine. It's an application framework with modules, dependency injection and decorators that runs on top of Express (the default) or Fastify. I covered the latest release in my NestJS 12 upgrade guide.

The code looks similar for a simple route. Here are the three handlers I benchmarked:

// Hono
app.get('/users/:id', c => c.json({ id: c.req.param('id'), fields: c.req.query('fields') ?? null }))

// Express 5
app.get('/users/:id', (req, res) => res.json({ id: req.params.id, fields: req.query.fields ?? null }))

// Fastify 5
app.get('/users/:id', async req => ({ id: req.params.id, fields: req.query.fields ?? null }))

How I benchmarked them#

Benchmarks of web frameworks are easy to get wrong, so here's exactly what I ran.

1. Machine. An 8 vCPU Intel Xeon VM with 15 GB of RAM. Each server was pinned to 2 cores with taskset. The load generator, oha 1.16.0, ran on the other 6 cores with 64 connections.
2. Runtimes. Node.js 24.22.0, Node.js 26.12.0 and Bun 1.4.3.
3. Versions. Hono 4.13.13 with @hono/node-server 2.1.5, Express 5.3.0, Fastify 5.12.7, and NestJS 12.1.3 with @nestjs/platform-express and @nestjs/platform-fastify. These were the latest npm releases on October 17, 2026.
4. Workloads. GET /json returns {"message":"Hello, World!"}. GET /users/42?fields=name reads a route parameter and a query string. POST /echo parses a 907-byte JSON body and returns a count.
5. Fair settings. No logging. ETags off in Express and in NestJS on Express, and x-powered-by off in Express. Fastify ran twice, once without schemas and once with response schemas. Every app returns the same JSON.
6. Method. Each run started a fresh server, warmed it up for 4 seconds, then measured for 10 seconds. I ran 3 rounds per setup and report the median. Four setups had one noisy round, so I re-ran those with 5 rounds. That's 32 setups and more than 65 million measured requests, with a 100% success rate.

Absolute numbers depend on hardware. The ratios between frameworks are what transfer to your servers.

Is Hono faster than Express?#

Yes. On Node 24, Hono handled 1.44× Express's throughput on plain JSON (73,067 vs 50,744 requests per second), 1.45× on route parameters and 1.28× on POST bodies. Latency followed: p99 on the JSON test was 1.50 ms for Hono against 2.12 ms for Express.

Two details matter more than the headline:

• Hono came within 8% of raw node:http on the JSON test. There's very little left to optimize in the framework itself.
• Hono's lead shrinks on POST. On Node, Hono goes through @hono/node-server, which turns Node's request into a web-standard Request before your handler sees it. Parsing a body through that layer costs more than Fastify's native parser. On Bun, where Request is native, the same Hono app did 80,749 POST requests per second, 2.2× its Node result.

Express 5 pays for its flexible middleware pipeline and the extra properties it adds to every request and response. It's still not slow. Fifty thousand requests per second on two cores is about 4 billion requests a day. Your database will give out long before Express does.

Hono vs Fastify: which is faster?#

It depends on the route. On Node 24:

Fastify's router is a radix tree (find-my-way), and it beat even my hand-written node:http router on the route parameter test (76,746 vs 73,049), because my raw version builds a URL object per request. Adding response schemas, which Fastify compiles into a serializer with fast-json-stringify, was worth only about 4% on these small responses. The bigger value of schemas is validation and documentation, not speed.

So on Node, call it a draw. Pick between them on design: web standards and portability (Hono), or schemas, plugins and Node depth (Fastify).

Fastify vs Express: is it worth switching in 2026?#

On raw speed, Fastify was 1.41× faster on JSON, 1.59× on route parameters and 1.36× on POST. Its p99 latency was 25 to 40% lower too.

Whether that justifies a rewrite depends on where your time goes. If a typical request spends 20 ms in Postgres and 0.3 ms in the framework, cutting the framework's share in half changes nothing a user can feel. Switch when profiling shows the framework near the top, when you want schema validation built in, or when you're starting fresh anyway. Don't switch because of a chart, including this one.

How much overhead does NestJS add?#

NestJS adds a layer of decorators, guards, pipes and interceptors on top of the engine. In my tests that cost 23% of Express's throughput (38,893 vs 50,744 on JSON) and 21% of Fastify's (56,434 vs 71,786). It also used more memory: about 100 MB idle versus 65 MB for plain Express.

The fix is easy and well documented in the NestJS performance guide: NestJS on Fastify was 1.45× faster than NestJS on Express on JSON and POST, and 1.66× faster on route parameters. It was also faster than plain Express on every test. If you use NestJS and none of your middleware is Express-specific, the Fastify adapter is the cheapest performance win available.

Do Node 26 and Bun change the ranking?#

Node 26 made every framework faster without code changes. On the JSON test, Express and Fastify gained about 12%, NestJS 10%, Hono 6% and raw node:http 7%.

On Bun, the ranking changes. Hono uses Bun's native server directly, so it ran 1.62× faster than on Node 24 and opened a 37% lead over Fastify. Express and Fastify also got faster on Bun (1.43× and 1.20×) but they run through Bun's node:http compatibility layer instead of calling Bun.serve directly. If you plan to run on Bun, Hono is the obvious choice. I compared the runtimes themselves in Bun vs Node.js in 2026.

Memory, startup time and install size#

Throughput isn't the only cost. Startup matters for serverless and autoscaling, and install size matters for container images and cold deploys.

Startup is the time from launching the process to the first successful response, measured with hyperfine over 20 runs. Hono on Bun was ready in 14 ms, which is why it's popular for serverless functions. NestJS needed about 2.8 times as long as the plain framework underneath it, because it scans modules and builds its dependency graph at boot.

Install size, measured in a fresh folder with npm: Hono plus its Node adapter is 2 packages and 3.9 MB. Express 5 is 65 packages but only 4.3 MB. Fastify is 48 packages and 14.4 MB. A minimal NestJS app on Express (core, common, platform-express, reflect-metadata, rxjs) is 98 packages and 22.4 MB. If you ship Docker images, my Next.js Dockerfile guide has the same multi-stage tricks that keep a Node API image small.

Which Node.js framework should I use in 2026?#

Two more points rarely show up in benchmark posts:

• Ecosystem. Express still has the most middleware, tutorials and Stack Overflow answers. Fastify's plugin ecosystem covers most production needs. Hono's middleware set is smaller but growing, and anything built on web standards tends to just work.
• Typed clients. Hono's RPC mode lets a frontend import the API's types directly. If your frontend is Next.js, also check whether you need a separate API at all; I covered that in Server Actions vs Route Handlers.

How do I migrate from Express to Hono or Fastify?#

You don't need a big-bang rewrite. Both frameworks can sit next to Express while you move routes.

// Fastify: run existing Express middleware during a migration
import Fastify from 'fastify'
import expressPlugin from '@fastify/express'
const app = Fastify()
await app.register(expressPlugin)
app.use(legacyExpressMiddleware)

// Hono: same handler shape on every runtime
import { Hono } from 'hono'
const app = new Hono()
app.get('/health', c => c.json({ ok: true }))
export default app // Bun, Workers, Deno; use @hono/node-server on Node

A safe order: move health checks and read-only routes first, measure them in production, then move the routes that write data. Keep the request and response shapes identical so clients never notice. Watch for Express habits that don't carry over: mutating req from middleware, res.locals, and error handlers with four arguments.

Common mistakes when benchmarking web frameworks#

• Running the load generator on the server's cores. Pin them apart, or you measure contention.
• Benchmarking only /hello. Hono won plain JSON, Fastify won routes with parameters and bodies. One endpoint gives you one answer.
• Leaving logging on. Fastify with a logger and Express with morgan are both much slower. Compare like with like.
• Trusting a single run. Four of my 32 setups had one round 10 to 20% below the others. Take the median of several runs.
• Comparing frameworks on different runtimes. "Hono is 2× faster than Express" is often Hono on Bun versus Express on Node.
• Ignoring where time actually goes. Profile one real request. The framework is rarely the bottleneck.

Related: if your API is meant for AI agents, read MCP vs API before choosing a framework, because the protocol choice changes more than the framework does.

Key takeaways#

• On Node 24, Hono (73,067 req/s) and Fastify (71,786) are tied on JSON, and both are about 1.4× faster than Express 5 (50,744).
• Fastify won route parameters (+9% over Hono) and POST bodies (+7%). Hono won plain JSON and came within 8% of raw node:http.
• NestJS costs about 21 to 23% throughput and about 2.8× the startup time. On the Fastify adapter it's 1.45 to 1.66× faster than on Express.
• Node 26 sped every framework up by 6 to 12% with no code changes.
• On Bun, Hono jumped to 118,432 req/s, 1.62× its Node result, with 14 ms startup and 43 MB under load.
• Hono installs as 2 packages (3.9 MB). Express is 65 packages (4.3 MB), Fastify 48 (14.4 MB), and NestJS 98 (22.4 MB).
• Even Express handled 50,000 requests per second on 2 cores. Pick on design and ecosystem first; the framework is rarely your bottleneck.