Fastify vs Express: which one for a new Node.js API

For a new Node.js API, pick Fastify if you want validated input, built-in logging, and a clear structure as the API grows. Pick Express if the API is small, your team already knows it, or you depend on middleware that only exists for Express. Both are fine. The choice matters less than most comparison posts claim.

What actually differs

Here are the differences that change how you write and run an API. I checked these against Fastify 5 and Express 5, the current major versions.

	Fastify	Express
Input validation	Built in. You describe the request with JSON Schema and Fastify validates it before your handler runs.	Not included. You add a library such as Zod, Joi, or express-validator and wire it in yourself.
Logging	Pino is built in and structured logs are one option away.	Not included. You add morgan or pino-http.
Structure	Plugins with encapsulation. A plugin can add routes, hooks, and decorators without leaking into the rest of the app.	A chain of middleware and routers. Simple, and easy to let grow into a tangle.
Async handlers	Async handlers work natively.	Express 5 passes a rejected promise from an async handler to your error handler.
TypeScript	Types ship with the package.	Types come from the separate @types/express package.
Ecosystem	Large plugin ecosystem, younger.	Largest ecosystem in Node.js, and the most examples and answers online.

A small benchmark I ran

I wrote the same two routes in both frameworks and load-tested them with autocannon: a GET that returns a small JSON object, and a POST that validates a body with two fields. Fastify used a JSON Schema. Express used a hand-written check.

Route	Fastify 5.12.8	Express 5.3.0
GET /json	about 101,000 requests per second	about 40,000 requests per second
POST /echo with validation	about 68,000 requests per second	about 35,000 requests per second

These are the median of three 8-second runs at 100 connections, on an Apple M4 with Node.js 26.13.0, with other apps open on the same machine. A first trial gave different absolute numbers, so read the result as “Fastify served roughly 1.5 to 2.5 times more requests per second on these routes”, without taking the exact figures too seriously.

A hello-world benchmark tells you little about your own API. In a real app, the database and external calls usually take far more time than the framework does. Pick on structure and team fit first, and measure your own routes before you decide that speed is the reason to switch.

When I would pick Express

• The API is small and will stay small.
• Your team already knows Express well and ships with it every week.
• You rely on a middleware or library that only supports Express.
• You need the widest choice of tutorials and answers for new team members.

When I would pick Fastify

• You want request validation to be part of the framework.
• You want structured logs from day one.
• The API will grow, and you want plugins to keep routes and shared logic separate.
• Throughput and latency matter, for example an API that sits behind a busy front end.

Moving from Express to Fastify without a rewrite

You do not need to stop and rewrite. A safe path is to move one route at a time and keep the tests passing. Fastify has an official plugin, @fastify/express, that lets Express middleware run inside a Fastify app, which helps while you move. Start with the routes that are slow or poorly validated, since those gain the most.

What x.com chose

X rebuilt its web app on React, Vite, Fastify, and TypeScript, according to its engineering report as covered by iTechPost on 5 November 2026. One large company picking a tool does not decide what is right for your API, but it shows that Fastify holds up at a very large scale.

Next steps

If you want a new API built on Fastify, or an Express app moved over, see my Fastify development service. If the API is fast and the database behind it is not, see database optimization. Or send me the API through the contact page. I reply within 24 hours.