What is the main difference between Express and Fastify?

Express is a minimal, unopinionated framework with by far the larger download base, giving you full control but no guardrails. Fastify is a performance-first framework with built-in JSON Schema validation and serialization that consistently benchmarks at 2 to 3 times Express's request throughput. Express has 15 years of ecosystem depth and, as of 2025, a major version bump: Express 5 is now the default version npm installs, with real breaking changes from 4.x. Fastify has an actively maintained core with a plugin architecture designed to enforce encapsulation at scale.

When should I choose Express over Fastify?

Choose Express when your team is primarily junior or mid-level engineers, when you depend on connect-style middleware that is not compatible with Fastify's plugin system, or when you need to integrate with legacy packages built against Express's req/res/next interface. Express's 445.7M monthly downloads mean your engineers have almost certainly used it before, which cuts onboarding time significantly. It is also the better choice for server-side rendered applications using view engines like EJS or Pug.

When should I choose Fastify over Express?

Choose Fastify for greenfield REST or GraphQL APIs where throughput matters, serverless deployments where CPU time per invocation appears on your cloud bill, or teams that have adopted TypeScript and want schema-to-type inference without extra tooling. Fastify's last commit landed today as of July 2026, signaling active maintenance. Its built-in Ajv validation and fast-json-stringify serialization eliminate an entire category of runtime bugs that Express applications have to solve separately.

Are Express and Fastify free to use?

Both Express and Fastify are MIT-licensed open source projects with no commercial tiers, no enterprise seats, and no paid support plans required. Total cost is purely operational: the infrastructure you run them on and the engineering time you invest in them. Neither project has announced any plans to introduce paid tiers as of mid-2026.

What is the biggest production gotcha with Fastify that teams discover too late?

Fastify silently drops response fields that are not declared in the route's JSON Schema during serialization. Your handler can return an object with ten fields, but if your schema only declares five, exactly five arrive over the wire with no error and no log warning. Teams typically discover this when a developer adds a new model field, writes a unit test that passes by checking the handler return value directly, deploys, and then spends days debugging why API consumers are missing data. Always update your route response schema when you add fields to your handlers.

How hard is it to migrate from Express to Fastify?

A small API with under 20 routes and no custom middleware typically takes one to two days for an engineer already familiar with Fastify. A large production application with 50 or more routes, session middleware, connect-compatible auth layers, and custom error handlers realistically takes two to four weeks. The hardest part is that connect-style middleware using req/res/next does not work in Fastify and must be rewritten as hooks or plugins. Running both frameworks in parallel during a phased migration is possible but doubles operational complexity during the transition period.

How does team size affect the Express vs Fastify decision?

Express suits small teams or solo engineers moving fast because its permissiveness removes friction at the start. Fastify suits teams of four or more where code review bandwidth is limited, because its scoped plugin system and mandatory schemas prevent a category of architectural mistakes that accumulate in Express codebases over time. Fastify's structure acts as a guardrail that junior engineers cannot accidentally bypass, which reduces the burden on senior engineers doing code review.

What are the real-world performance limits of Express vs Fastify?

On a typical four-core cloud VM serving a plain JSON endpoint, Express tops out around 15,000 to 20,000 requests per second. Fastify on the same hardware consistently reaches 45,000 to 65,000 requests per second in repeatable autocannon benchmarks, driven by radix tree routing, fast-json-stringify serialization, and an async-first hook lifecycle. Below 5,000 requests per second the difference is academic for most teams. Above 20,000 requests per second the Fastify advantage translates directly into fewer instances, lower cloud spend, and more headroom before your next capacity upgrade.

Express or Fastify?

Not in general. For your service. Tell us one thing and we'll answer it, free, with reasons you can put in front of the people you're arguing with.

Which sounds like your project?

One tap. No sign-up. Full comparison below.

Tech Duel

Express vs Fastify

Q: Did Express 5 actually change anything that matters?

Yes, and it's easy to miss if you haven't looked since before 2025. Express 5.1 became the default version installed by npm install express after a roughly ten-year wait for a major release. The most consequential change is new path route matching syntax: routes using regex fragments, optional parameters, or wildcards follow different rules than in 4.x, and a route that worked correctly in 4.x can silently match a different set of paths in 5.x with no error. Express 5 also properly propagates rejected promises from async handlers to error-handling middleware, which surfaces errors that 4.x silently swallowed, and it requires Node.js 18 or later.

Express is the minimal, unopinionated default with 15 years of ecosystem depth, now on a major version (5.1, the npm default since 2025) with real breaking changes from 4.x. Fastify is a performance-first framework with built-in schema validation that benchmarks 2-3x Express's throughput. The right pick depends on your team's tolerance for guardrails, your performance requirements, and whether you're starting fresh or maintaining a 4.x codebase.

Last reviewed: July 2026

Quick verdict: Express vs Fastify

Choose Express if your team already runs Node.js microservices with an existing middleware chain, you're hiring junior engineers who need a gentle learning curve, or you integrate with legacy packages built against Express's req/res objects.

Choose Fastify if you're building a greenfield API where throughput matters, you have a senior engineer to own schema validation, and you can't afford the CPU cost Express accumulates at scale.

If you're on Express, check whether you've actually migrated to 5.x yet. Its path-matching change can silently alter route behavior.

When to choose Express vs Fastify

Choose Express when…

Your team already runs Node.js microservices with an existing Express middleware chain
You're hiring junior engineers who need the gentlest possible learning curve
You integrate with legacy npm packages that assume Express-compatible req/res objects
You value the largest ecosystem and answer base over raw request throughput
You've budgeted time to validate routes against Express 5's new path-matching rules before upgrading

Choose Fastify when…

You're building a greenfield API where throughput and per-request CPU cost matter
Your team has at least one senior engineer to own JSON Schema validation setup
You've adopted TypeScript and want schema-to-type inference without extra tooling
You're deploying to serverless where CPU time per invocation shows up on your bill
You want a schema/handler mismatch to be a compile-time error, not a runtime bug

Express vs Fastify: at a glance

Dimension	Express	Fastify
Philosophy	Minimal, unopinionated	Performance-first, schema-driven
Current major version	5.1, the npm default since 2025	Actively maintained, frequent releases
Recent breaking change	5.x path-matching syntax differs from 4.x. Can silently match different routes	No comparable recent breaking change
Async error handling	5.x now propagates rejected promises properly (4.x silently swallowed them)	Async-first by design from the start
Throughput (plain JSON, 4-core VM)	~15,000-20,000 req/s	~45,000-65,000 req/s
Validation	Community middleware (Joi, express-validator)	Built-in JSON Schema + Ajv
TypeScript support	Community @types/express, no schema inference	Native, schema-to-type inference
Middleware compatibility	Native connect-style req/res/next	Needs @fastify/middie compat layer, reintroduces overhead
Node.js requirement	18+ as of Express 5	Check current Fastify major version requirements
Ecosystem size	Larger, 15 years of packages	Smaller but growing, official plugin registry

Express vs Fastify: what Express 5 actually changed

Express 5.1 became the version npm installs by default in 2025, after roughly a decade since the first pull request toward a major release. If your comparison research predates that, you're reading about a framework that's since changed underneath you. The most consequential change is new path route matching: routes using regex fragments, optional parameters, or wildcards follow different rules than in 4.x. A route that worked correctly in 4.x can silently match a different set of paths in 5.x, with no error thrown, which is exactly the kind of change that passes tests and breaks in production.

Two more changes matter operationally. Express 5 now properly propagates rejected promises from async middleware and handlers to your error-handling middleware, whereas 4.x silently swallowed them, meaning code that relied on that swallowing behavior now surfaces errors it didn't before. And Express 5 requires Node.js 18 or later, which is a non-issue for most current deployments but worth checking if you're running anything legacy.

None of this touches Fastify directly, but it does change the comparison's framing. Part of Express's traditional advantage was "boring and stable" against Fastify's faster-moving ecosystem; a major version with real breaking changes narrows that gap, at least for the migration window while teams update their routes.

If you're still running Express 4.x deliberately, that's a defensible choice, but audit your routes against the 5.x path-matching rules before you upgrade, don't assume a clean `npm update` is safe.

Express vs Fastify: schema validation and the TypeScript story

Fastify's built-in JSON Schema validation is more than a performance feature. It's a correctness one. Declare a schema for a route's response and Fastify's fast-json-stringify serializer uses it to build an optimized serialization function, which is where a meaningful chunk of the throughput advantage comes from. The tradeoff: fields your handler returns that aren't declared in the schema are silently dropped from the response, no error, no warning, which is the production gotcha below.

Express has no equivalent built in. Request validation is typically bolted on via community middleware like Joi or express-validator, and there's no serialization-layer schema at all, Express just calls JSON.stringify on whatever your handler returns. That's more flexible and has zero surprise-dropped-fields risk, but it also means nothing catches a shape mismatch between what you meant to return and what you actually returned.

For TypeScript specifically, Fastify's schema definitions connect to handler parameter types, so a mismatch between your declared schema and your handler logic becomes a compile-time error. Express's TypeScript story relies on the community-maintained @types/express package, which types req and res but infers nothing from your actual route definitions.

If schema-driven correctness matters more to your team than maximum flexibility, that's a real Fastify advantage independent of raw throughput.

Express or Fastify, by situation

We have years of custom Express middleware in this app: Express. Connect-style middleware does not work in Fastify's hook system. @fastify/middie re-introduces the overhead you moved for, and middleware built against Express internals is a rewrite, not a port.
Greenfield API, and CPU per request shows up on our bill: Fastify, not Express. On plain JSON on a 4-core VM this page puts Express at 15,000 to 20,000 req/s and Fastify at 45,000 to 65,000 req/s. On serverless you pay that gap on every invocation.
We're hiring juniors and lean on npm packages and answers: Express. Express brings 15 years of packages and the largest answer base, at 445.7M monthly downloads. Fastify's smaller ecosystem means more custom plugin work, which is what a junior-heavy team has least of.
TypeScript throughout, and we want schemas to catch mistakes: Fastify. Fastify ties JSON Schema definitions to handler types, so a schema and handler mismatch fails at compile time. Express leans on community @types/express, which infers nothing from your route definitions.

Common questions about Express vs Fastify

Is Fastify actually faster than Express in production, or just in benchmarks?

It is faster in production too, but the gap depends on your payload shapes. Fastify's serialization advantage is largest on responses with many fields and high request volume. On a service doing 1,000 requests per second with small payloads, you will not feel the difference day-to-day. On a service doing 30,000 requests per second with complex JSON responses, Fastify's CPU savings are measurable on your cloud bill. The benchmark numbers (2 to 3x Express throughput) are achievable but assume you have actually written JSON Schemas for your routes. Skip the schemas and you leave the performance gains on the table.

Can I use my existing Express middleware in Fastify?

Not directly. Connect-style middleware that uses the req/res/next signature is not compatible with Fastify's plugin and hook system. Fastify provides a compatibility layer called @fastify/middie that wraps connect middleware, but it re-introduces the performance overhead you switched to Fastify to escape and it does not support all edge cases. For simple middleware like compression or CORS, official Fastify plugins exist and are the right answer. For custom internal middleware built against Express internals, plan a rewrite, not a port.

Which framework has better long-term support prospects in 2026?

Both look healthy. Express has 69.2k stars, 445.7M monthly downloads, and its last push was three days ago, meaning the core team is still active despite its maturity. Fastify's last commit was today, its maintainers are responsive on GitHub, and its download growth rate is outpacing Express's. Neither project shows signs of abandonment. If forced to bet on momentum, Fastify's trajectory is steeper, but Express's installed base is so large that critical security patches will keep coming for years regardless.

Does Fastify work well with TypeScript?

Yes, and this is one of the strongest arguments for choosing it on new projects in 2026. Fastify ships with type definitions that connect your JSON Schema definitions to handler parameter types, so a mismatch between your declared schema and your handler logic becomes a compile-time error rather than a runtime bug. Express's TypeScript story relies on the community-maintained @types/express package, which gives you types for req and res but provides no inference from your route definitions. If TypeScript correctness across the full request/response lifecycle matters to your team, Fastify's native integration is a meaningful advantage.

What happens if I pick the wrong framework and need to switch later?

Switching from Express to Fastify on a mature application is painful but survivable. The realistic estimate for a 50-plus route API is two to four weeks of engineering time, mostly spent rewriting connect middleware as Fastify plugins and adding JSON Schemas to every route. Switching from Fastify back to Express is less common but faster because Express imposes fewer constraints, meaning Fastify patterns mostly map directly to Express handlers with some middleware added. The real cost of switching is not the code change, it is the time your team is not shipping features. Make the decision carefully upfront using the quiz above rather than treating it as easily reversible.

Do I need to upgrade to Express 5 right now?

Not urgently, but don't ignore it either. Express 4.x still works and receives security patches, so there's no forced deadline. The risk is drift: the longer you wait, the more routes and middleware accumulate on 4.x assumptions that need re-validating against 5.x's path-matching rules when you eventually do upgrade. Budget the migration deliberately, write out your route patterns and test them against Express 5's matching behavior, rather than running `npm update` and assuming your test suite will catch everything.

Sources

Figures on this page were taken from the vendors themselves and checked in July 2026.