Why I migrated from NestJS-Fastify back to NestJS-Express

A while ago, I led a project using NestJS with Express as the default HTTP adapter. Wanting to optimize performance, we migrated to NestJS with Fastify, which promised better throughput and lower overhead.

Here’s what happened:

🔍 The context:
We were building internal tools and APIs where performance mattered, but not at hyperscale. As a tech lead, I wanted to explore Fastify’s performance benefits for future readiness.

⚙️ What we ran into:
Some libraries and middlewares were incompatible or needed awkward wrappers.
Debugging and plugin behavior wasn’t as predictable.
Junior developers had a steeper learning curve, especially when troubleshooting.

📉 The result:
The performance gain was marginal for our use case, and the developer experience regressed. We realized it was a case of premature optimization, especially for a product still evolving.

✅ What we did:
We migrated back to NestJS-Express, regained developer velocity, and reduced mental overhead. For our needs, stability and compatibility mattered more than micro-benchmark gains.

Takeaway:
If you’re leading a team and considering Fastify for NestJS, it’s worth testing. But make sure the trade-offs align with your team’s skills and actual performance goals.

Have you tried this migration? Curious to hear how it went.
👉 Drop a comment or DM me if you’re deciding between Express and Fastify. Happy to share more from the trenches.