Hono vs Express vs Bun for SaaS API Servers in 2026

If you're choosing an API stack for a SaaS product, write down two separate decisions before you compare anything: which runtime hosts the process, and which framework shapes the handlers. Bun is an answer to the first question, Hono and Express are answers to the second, and mixing the two questions is what makes this comparison feel harder than it is.

The most useful first action is small. List the dependencies your API can't live without, such as password hashing, an ORM, an image or PDF library and your payment SDK, and check each against the runtime you're considering. That list shrinks the decision faster than any benchmark. If you want the vocabulary first, my explainer on what a REST API is covers the request-and-response layer all three tools sit on.

Which of Hono, Express and Bun Is Not a Framework?

Bun is a JavaScript runtime, not a web framework, so it competes with Node.js and Deno, while Hono and Express are the two frameworks in this comparison and can run on the runtimes.

Bun's own Express guide says Express and other major Node.js HTTP libraries should work in Bun without changes, because Bun implements node:http and node:https. Hono goes the other direction. Its documentation says it works on any JavaScript runtime: Cloudflare Workers, Fastly Compute, Deno, Bun, Vercel, Netlify, AWS Lambda, Lambda@Edge and Node.js. So "Hono or Bun" is closer to "screwdriver or workbench" than a real fork in the road.

The size row comes from Hono's own documentation, so it's a vendor comparison, and it matters mostly where startup cost matters. Answer the runtime question first, then the framework one.

Hono vs Express: Does Performance Decide It?

Rarely. Hono's benchmark page shows leading results on Cloudflare Workers and Deno, but it opens by saying benchmarks are only benchmarks, and in a typical SaaS handler your database dominates the time.

The Hono benchmarks page reports 402,820 ops/sec for Hono on Cloudflare Workers and 136,112 requests per second for Hono on Deno, in its own router comparisons. Those are useful for comparing routers against each other, and they say nothing about your API. My reasoning is simple: a handler that authenticates, reads one row, writes one row and serialises JSON spends far more time waiting on the database than routing the request, so an unindexed query costs more than the difference between two routers. I haven't run a Hono versus Express benchmark for this post and won't quote numbers from someone else's setup.

How many requests per second does your API actually serve at peak? If you can't read that from a dashboard, the benchmark table is entertainment.

Where the framework's size does help is serverless. A 14kB framework has less to load per invocation than a 572KB one, which is an inference from the size numbers, and it's a different argument from raw throughput. My glossary entry on serverless explains why per-invocation startup cost matters in that model.

How does testing compare?

Hono is short here. Its testing guide shows app.request('/posts'), which builds a Request, passes it to your app and returns the Response you assert on, with an optional third argument for mock environment bindings. There's no server to boot and no port. Express testing works fine, it just needs a test HTTP library on top of the app.

Is Express Still Maintained, and What Should You Use Instead?

Yes. Express's support page lists v5.x and v4.x as currently supported, and its GitHub releases page shows 5.2.1 and 4.22.2 among the recent releases, so treat it as a maintained project.

The Express support page says only the latest release of each supported major line gets fixes, and that v5.x has been supported since September 2024. Reports of its death don't match the release history. That doesn't make it the right choice for a new API, but it does make it a defensible one for an existing API. The real question is switching cost, not which project is still alive.

The reason to think twice before migrating is the middleware contract. Express gives you (req, res, next). Hono's middleware guide gives you (c, next), a single context object and an awaited next(). There's no official bridge. The proposal for one, honojs/hono issue #3293, has been open since 18 August 2024, and the stated blocker is that "Hono's Context object doesn't directly map to Express's req and res objects". So session handling, Passport strategies and the custom error handler nobody has read in years are each a rewrite or a reason to stay put. My advice, and it's a recommendation rather than a measured result, is to port stateless JSON routes first, run both apps behind one proxy, and leave auth and sessions for last.

How do you use Hono with Next.js?

If you're on Next.js already, Hono can own your API routes. Per Hono's Next.js guide:

1. Create app/api/[[...route]]/route.ts. The optional catch-all segment lets one file handle every API path.
2. Instantiate with a base path: const app = new Hono().basePath('/api').
3. Define routes on that instance with .get(), .post() and the rest.
4. Export the method handlers with handle from @hono/vercel: export const GET = handle(app) and export const POST = handle(app).

The draw is middleware composition and end-to-end types. Hono's RPC guide explains that you export typeof your app as AppType, write validators on the server, and create a client with hc<AppType>() that infers request and response types. That pays off when your codebase is typed end to end already.

Where Does Bun Fit for a SaaS API?

Bun fits when your dependencies run on it and you accept a fast release cadence: its releases page lists v1.4.2 on 5 September 2026, so pin a version and read the notes before upgrading.

The Bun 1.3 announcement, published on 10 October 2025, describes what moved into the runtime: Bun.serve() with parameterized and catch-all routes and per-method handlers, a unified SQL API for PostgreSQL, MySQL, MariaDB and SQLite, and a built-in Redis client with 66 commands that Bun's own benchmark puts at more than 7.9 times the performance of ioredis. That last figure is a vendor benchmark, so test it on your workload. Elsewhere in Bun's docs, Bun.password supports Argon2 and bcrypt without a native addon, and bun:sqlite is a built-in SQLite driver.

Read that as a strategy change: for a small internal service with a dozen endpoints, the runtime may cover routing, database access and caching without a framework. Once you want composable middleware, typed route groups, validation and an RPC client, that's the job Hono does. The line is a judgement call, not a number.

The Bun Node.js compatibility page is the place to check before committing. It marks node:vm as fully implemented and node:cluster as partially implemented and "not battle-tested", with HTTP load-balancing across processes supported only on Linux. If your process model depends on clustering, test that first.

Here is a practical order for the dependency check. Run your existing test suite on Bun in CI alongside Node for a week of commits, then add the database driver and the payment SDK's webhook signature check, since those touch raw request bodies. Anything that fails is a reason to keep that service on Node, and because Hono handlers are portable you can make that call per deployment instead of per rewrite.

Which one should you pick this week?

For a new SaaS API where you control the runtime, I'd start on Hono and run it on Node or Bun, whichever passes your dependency check, because Hono's web-standard handlers can move between runtimes later. For an existing Express service that works, leave it alone. A migration costs more than a benchmark difference returns, and Express 5 is maintained.

There's also a case where the question doesn't arise. BookBed, which I built solo as a Flutter app on Firebase and Stripe for six platforms, has no separate API server framework in its stack description. That's an inference from the case study, not a claim about every line of its backend, but it shows that a product where the client does most of the work may never need this comparison. The SaaS MVP stack guide walks the decision from the product outward.

So open your APM, pick one real endpoint and look at its p95. What share of that time is spent outside your database?