Should You Leave Nx? 3378ms vs 1177ms

On a 7-package npm workspaces monorepo (336 JavaScript source files), Turbo 2.11.7 took a cold median 1177 ms and Nx 23.2.1 took 3378 ms (~2.9x). Warm local cache was 7/7 hits for both: Turbo wall median 138 ms (tool Time ~16 ms FULL TURBO), Nx wall median 668 ms with the daemon on (tool Run duration ~31 ms).

Short answer: leave Nx for Turbo when you want a thin task runner and faster cold CI on a simple package-script graph. Keep Nx when you need generators, project graph plugins, and a full monorepo framework. No affiliate links in this post.

What I tested

• Machine: 8 vCPU Intel Xeon / 15 GB RAM Linux cloud box, Node 20.19.2, tested 5 Oct 2026 (about 23:35 to 23:45 IST). Shared box; tools interleaved each round.
• Fixture: npm workspaces with 6 libraries (@bench/pkg-a … pkg-f) and 1 app (@bench/web), 336 .js files under src/. Each build script reads its src/, does a small CPU hash loop, and writes dist/index.js.
• Tools: turbo 2.11.7 (turbo run build) and nx 23.2.1 (nx run-many -t build --all). Turbo packageManager field set; Nx targetDefaults.build.cache with outputs {projectRoot}/dist/**.
• Timing: five interleaved cold runs (Turbo --force; Nx --skip-nx-cache), then five interleaved warm cache-hit runs. Warm Nx measured with NX_DAEMON=true after a daemon warmup. Wall-clock via perf_counter around the full CLI.
• Findings: cold medians Turbo 1177.19 ms (1133 / 1177 / 1196 / 1177 / 1299) vs Nx 3377.905 ms (3209 / 3135 / 3378 / 3440 / 3443). Warm: both 7/7 cache hits; Turbo wall 135–152 ms (tool Time 13–26 ms); Nx wall 625–715 ms (tool Run duration 30–36 ms).
• One surprise: on cache hits the tools themselves report similar task times (~16–31 ms), but Nx wall clock stayed higher because each CLI call still pays Node startup even with the daemon on.
• Not tested: remote cache (Vercel Remote Cache / Nx Cloud), affected-only runs, Nx generators or @nx/* executors beyond nx:run-script, pnpm/yarn workspaces, Windows/macOS, a 100+ package graph.

Is Turbo faster than Nx on cold builds?

Tool	Cold median (wall)	Cold runs (ms)	Warm cache	Warm wall median	Tool-reported warm
Turbo 2.11.7	1177 ms	1133 / 1177 / 1196 / 1177 / 1299	7/7	138 ms	~16 ms FULL TURBO
Nx 23.2.1	3378 ms	3209 / 3135 / 3378 / 3440 / 3443	7/7	668 ms	~31 ms Run duration

On this fixture Turbo finished cold builds about 2.9x faster. Both restored from local cache on every warm run. If your CI is mostly cold or cache-miss work on npm-script tasks, Turbo's lower overhead showed up clearly here.

Monorepo task runners sit next to bundler and package-manager choices. The Rspack vs Webpack post and the Rolldown vs Rollup post cover compile/bundle speed; the pnpm vs npm vs Bun post covers install speed. This post is only the task-orchestrator decision. For a Turbo point-release note on this site, see Turborepo 2.11.7.

What do you lose leaving Nx?

Nx is a monorepo platform, not only a cache wrapper. You lose first-party generators, inferred project graph plugins, module-boundary rules, and Nx Cloud workflows if you drop it for Turbo alone. Teams already deep in @nx/react or @nx/next executors should not treat this 7-package npm-script bench as a migration green light.

Also expect different config shapes. Turbo stayed close to package.json scripts plus turbo.json tasks. Nx needed explicit outputs under targetDefaults before local cache hit 7/7 on this fixture.

Should you leave Nx for Turbo?

Situation	My pick
Thin npm/pnpm workspaces, scripts already define build/lint/test	Prefer Turbo; re-measure your graph
You need generators, boundaries, or Nx plugins	Stay on Nx
CI is mostly cold or cache-bust builds on small packages	Turbo's cold ~2.9x here is the signal to test
You already pay for Nx Cloud remote cache and it is warm	Stay; this lab did not test remote cache
First PR would rewrite every project.json / executor	Stay on Nx unless the team wants a thin runner

Bottom line: on 7 packages and 336 JS files, Turbo cold median was 1177 ms and Nx was 3378 ms, with both hitting full local cache when warm. Who should not switch yet: teams that depend on Nx generators and plugins. Everyone else comparing task runners should run the same cold/warm pair on their own workspace.

How this was made: I built the workspaces fixture, ran interleaved Turbo and Nx builds on the ShopperCove test box, and kept the timing JSON; the write-up was drafted with AI help and checked against that output.

Sources

• https://turbo.build/repo/docs
• https://github.com/vercel/turborepo
• https://nx.dev/docs
• https://github.com/nrwl/nx
• https://www.npmjs.com/package/turbo
• https://www.npmjs.com/package/nx

Related

• https://www.shoppercove.com/blog/turborepo-2-11-7-sdkroot-oidc-cache-october-2026
• https://www.shoppercove.com/blog/rspack-vs-webpack
• https://www.shoppercove.com/blog/rolldown-vs-rollup
• https://www.shoppercove.com/blog/pnpm-vs-npm-vs-bun
• https://www.shoppercove.com/blog/swc-vs-esbuild-babel
• https://www.shoppercove.com/blog/vite-8-3-2-renderbuilturl-bundled-dev-sourcemaps-october-2026
• https://www.shoppercove.com/blog/jest-vs-vitest
• https://www.shoppercove.com/blog/typescript-7-should-you-upgrade