Turbopack is stable and on by default in Next.js 16. For new projects deploying on Vercel with straightforward plugin needs, switching today is reasonable. For anything outside Next.js, the question is moot — Turbopack does not run there, and Vite is still the answer.

Who this is for

Senior JS devs and tech leads choosing a bundler for a new or existing Next.js project. If your stack isn’t Next.js — Remix, SvelteKit, Astro, Nuxt, plain React — stop here. Turbopack is Next.js-only, and none of what follows changes your tooling decision.

What we reviewed

This article synthesizes first-party release notes (Next.js 15.3, 15.4, 16, 16.2), Vercel’s own benchmark reports, an independent third-party test by Catch Metrics on Cal.com (Next.js 15.5.2), Evan You’s public methodology review of the 10× HMR claim, and the 2025 State of JavaScript survey covering ~20,000 developers. Open GitHub issues were verified against Next.js 16.2.6 on 2026-05-30. No original benchmarks were run for this article; the caveats section explains how to run them yourself.

What changed since Next.js 15

Turbopack’s path to stability went through several public milestones over roughly 18 months:

Date	Milestone
Oct 2024	`next dev --turbo` declared stable for development. Production builds at 96% integration test pass rate.
Apr 2025 (Next.js 15.3)	`next build --turbopack` reaches alpha. 99.3% of 8,298 integration tests pass. Vercel’s own docs: “We don’t recommend using them in production for mission-critical applications at this stage.” More than 50% of Next.js 15 dev sessions are already on Turbopack.
Jul 2025 (Next.js 15.4)	100% of 8,298 integration tests pass. Production builds declared safe but not yet the default.
Oct 2025 (Next.js 16)	Turbopack is fully stable and the default bundler for all new Next.js projects. At launch, >50% of dev sessions and 20% of production builds on Next.js 15.3+ are already running Turbopack.
Mar 2026 (Next.js 16.2)	Performance and parity improvements continue. CI/CD hash-mismatch bug (GitHub #87737) remains open.

The practical shift: create-next-app now generates a Turbopack project. Existing webpack users must opt out with --webpack; the burden has flipped.

Turbopack vs. Vite: the benchmarks, honestly

What Vercel claims — and what that means

Vercel’s headline numbers come from measuring their own Vercel.com codebase:

Local server startup: up to 76.7% faster than webpack
Fast Refresh (code updates): up to 96.3% faster than webpack
Initial route compile (no cache): up to 45.8% faster than webpack

“Up to” peak figures on a single large production app are useful as directional signals, not as expected outcomes. Independent testing by Catch Metrics on Cal.com (a different large Next.js codebase) found the real improvement closer to 19% faster cold builds — and flagged a +211 kB regression in shared client chunk size. That regression matters for TTI on initial page load.

Both data points are real. Neither is the number you’ll get on your app. If production build performance is the deciding factor, measure it on your own project before committing.

The 10× HMR claim against Vite — what went wrong

Vercel published a benchmark claiming Turbopack runs “10× faster than Vite” at HMR. Evan You (Vite’s creator) reviewed the methodology publicly and found two specific problems.

Problem 1 — Mismatched transform pipelines. The benchmark ran Vite with Babel transforms and Turbopack with SWC. Vite’s SWC plugin wasn’t included in the comparison. That isn’t a Vite-vs-Turbopack measurement; it’s a Babel-vs-SWC measurement wearing bundler clothing.

Problem 2 — A measurement bug. The hmr_to_eval metric in the benchmark was reporting hmr_to_commit numbers for Vite, inflating the measured gap. Once corrected, the actual HMR advantage at typical module counts narrows to below 2× — roughly 100ms vs. 54ms — rather than 10×. Evan You’s public characterization of the original: “aggressive marketing using cherry-picked, non-peer-reviewed, borderline-misleading numbers.”

The honest answer for Turbopack vs. Vite 6 on HMR: there is no confirmed neutral third-party benchmark covering cold start, HMR, and production build on comparable project sizes. Turbopack’s HMR advantage over Vite is probably real and probably below 2× at typical module counts. If you need the exact delta for your codebase, clone the Next.js commerce template, measure cold start, HMR on a leaf component, and a full production build — first with Turbopack default, then with next build --webpack, then against a comparable Vite + React Router 7 baseline. That is the only number worth trusting for your specific setup.

Production build: still a question mark

Turbopack’s development-mode speed gains come from a fundamentally different architecture — Rust, incremental computation, demand-driven evaluation. Those properties shine when you’re iterating: partial rebuilds, fast HMR. Production builds are a different workload. Vite’s production path (Rollup under the hood) has years of optimization tuning. Turbopack’s production build is newer code. The integration test pass rate tells you correctness, not speed. At this point in 2026, production build performance is something to measure, not assume.

The ecosystem gaps that will block you

No plugin system

This is the largest structural limitation, and it is not a minor one. Turbopack has no plugin API for library authors.

What that breaks in practice:

Sentry source maps. Sentry’s standard integration relies on a webpack plugin to upload source maps at build time. The officially supported path does not exist in Turbopack yet. Partial workarounds exist via Sentry’s uploadSourceMaps configuration option, but they are not the same as the plugin-based workflow and require manual verification per setup.

Service Workers and PWA libraries. Serwist, Workbox, and similar libraries that register and configure Service Workers through webpack plugins have no Turbopack equivalent. If your app needs offline support or installable PWA behavior, you are staying on webpack.

CSS-in-JS with server-side extraction. Libraries that extract critical CSS at build time through webpack plugin hooks — certain configurations of styled-components, Emotion with SSR — have no Turbopack migration path.

Shared Workers and Audio Worklets. Not implemented as of Next.js 16.2.

There is no public delivery date for a Turbopack plugin API. If any of the above affects your project, webpack is still the path. The migration gate is “when the plugin system ships,” not “when Turbopack is stable.”

The CI/CD hash-mismatch bug

GitHub issue #87737, filed December 2025, is still open against Next.js 16.2.6 as of 2026-05-30. The root cause: Turbopack generates external module reference hashes based on the node_modules structure at build time. When dependencies are reinstalled in a different environment — Linux CI vs. macOS dev machine, pnpm vs. npm, different hoisting behavior — the hash changes and the runtime can’t find the module.

Reproducible on: pnpm + Linux CI, Prisma users, Pino users. 25+ affected commenters on the thread as of May 2026. The only confirmed workaround is next build --webpack.

If your pipeline uses pnpm on a Linux runner, do not ship Turbopack in production until this is resolved. Check the thread against your exact Next.js version before building that pipeline.

Outside Next.js: not on the roadmap

Turbopack is Vercel-funded and Next.js-scoped. There is no standalone bundler distribution, no Remix support, no SvelteKit support, no Nuxt support. A GitHub discussion thread (Next.js #86533) on a standalone Turbopack path is open but inactive. If your team wants consistent tooling across frameworks, Vite is the only choice. For the Vite vs. webpack trade-offs if you’re migrating an existing project, see Vite vs. Webpack.

What does work

Web Workers via the standard new Worker(new URL('./worker.js', import.meta.url)) pattern are implemented and working. Turbopack’s own loader system (turbopack.rules in next.config.ts) is functional — with the caveat that a known crash when combining custom loaders with Next.js middleware (GitHub #79592, partially fixed September 2025) is still reported as open in some configurations. Verify your loader + middleware setup before upgrading.

What developers think

The 2025 State of JavaScript survey (~20,000 respondents, published early 2026) has the clearest aggregate signal:

Vite satisfaction: ~98% — the highest figure in the build tools category by a significant margin
Turbopack satisfaction: ~66% — the survey editors describe this as “quite worrying”
Usage (all JS projects, not just Next.js): webpack 87%, Vite 84%, Turbopack 28%

The 28% Turbopack usage figure is driven largely by Next.js 16’s default adoption — users who are running Turbopack because it shipped with their framework, not because they chose it. That matters when reading the satisfaction number: 34% dissatisfied includes developers who didn’t opt in and found gaps they weren’t expecting.

The survey editors’ read on Turbopack’s growth: “Turbopack is showing a lot of progress in terms of usage, no doubt benefiting from being bundled with Next.js.” On the satisfaction gap: the 66% figure tracks alongside Next.js’s own declining satisfaction trend — two signals pointing in the same direction.

GitHub sentiment on the plugin system gap is pointed. One comment from issue #78784: “Unfortunately Turbopack also has no (not yet) a plugin system package authors could use to bridge this gap — and there is no mention about the plans to have a plugin system.” On the CI/CD hash bug, the thread includes affected users on Vercel Serverless, Windows Server 2022, and standard Linux CI runners — this is not an edge case.

Verdict

Switch to Turbopack if:

Greenfield Next.js 16+ project with no webpack plugin dependencies
Deploying on Vercel — tightest integration, least configuration overhead
Simple tooling stack: no Sentry source maps, no Service Workers, no CSS-in-JS with SSR extraction
You’ve verified GitHub #87737 doesn’t affect your CI setup (or you’re on npm with consistent environments)

Validate before switching if:

You use Sentry — test the uploadSourceMaps workaround in your exact pipeline before assuming it works
Your CI uses pnpm on Linux — reproduce the hash-mismatch scenario on a staging pipeline first
You have custom loaders combined with Next.js middleware — test the specific combination against GitHub #79592’s current status

Stay on Vite if:

Your project isn’t Next.js — Turbopack is not available, end of discussion
You’re deploying to Netlify with a Vite-based stack — the setup is proven and migration adds risk without payoff
Your tooling relies on webpack plugins that have no Turbopack equivalent
You need cross-framework consistency (Vite runs on Remix, SvelteKit, Astro, Nuxt, plain React)

Stay on webpack if:

GitHub #87737 is hitting your pipeline and next build --webpack is your working state
You have deep webpack customizations through plugins not yet portable to Turbopack loaders

Vite at 98% satisfaction vs. Turbopack at 66% is the single most useful data point in this comparison. Turbopack has made real engineering progress — stable, default, 100% integration test parity is not a small milestone. But “stable” means “correct,” not “complete.” The plugin system gap, the CI bug, and the satisfaction data all point at the same conclusion: Turbopack works for the common case today. The less common cases are the ones worth checking before you commit. For a focused head-to-head on benchmarks and DX, see Turbopack vs. Vite.

Caveats

No original benchmarks were run for this article. Vercel’s figures are vendor-reported peak numbers from their own codebase. The Catch Metrics study is a single third-party data point on one project. For production build performance, run your own benchmark: time next build with and without --turbopack on your actual project, repeated three times, fresh node_modules each run.

Toolchew has affiliate relationships with Vercel, Netlify, and Sentry. These relationships did not affect the verdict. The CI/CD bug and plugin system gap are described as-is; an affiliate relationship with Vercel did not soften the language on either.

GitHub issues #87737 and #78784 were verified against Next.js 16.2.6 on 2026-05-30. If significant time has passed since that date, check both threads for a resolution before citing the status.

Turbopack 2026 review — does it finally beat Vite?