every few months someone asks me this. "should i switch to fastify?"
probably not.
fastify is good. well designed. fast. but here's the thing: you're not netflix. you're not processing millions of requests per second. the performance difference between express and fastify doesn't matter for your app.
benchmarks lie
fastify is 2-3x faster than express in benchmarks. sounds impressive.
but those benchmarks measure returning "hello world" as fast as possible. no database. no business logic. no real work.
in a real app, your handler hits the database. 50ms. calls external apis. 100ms. runs business logic. the framework overhead? maybe 1-2ms. you're optimizing 1% of your latency.
i've seen teams spend weeks migrating to fastify chasing performance. their p99 barely moved. know what actually helped? adding a database index.
ecosystem matters
express has been around for 15 years. every library has express middleware. passport. multer. helmet. you can google any problem and find answers.
fastify? you'll wrap express middleware with @fastify/express. or write adapters. the ecosystem exists but it's smaller.
sometimes you just want to install a package and move on.
when fastify makes sense
there are real reasons to pick fastify:
- new typescript project and you want first-class types
- high-throughput stuff like api gateways
- serverless where cold start matters
- you'll actually use the schema validation
notice what's not on that list? "because benchmarks" or "because it's modern."
what i actually do
i use express for most things. it works. everyone knows it. i can hire someone and they're productive day one.
picking the "optimal" framework is overengineering. your users don't care if you used express or fastify. they care if it works.
real performance wins
if you care about performance, look here:
- database queries and indexes
- caching
- n+1 problems
- connection pooling
fix those first. i guarantee they have 100x more impact than express vs fastify.
stop optimizing things that don't matter.