Turbo vs Lage: 1.97s vs 3.01s Cold Build

I timed Turbo 2.11.7 and Lage 2.17.0 on the same 4-package npm workspace with a diamond task graph: cold build wall medians were 1.97 s for Turbo and 3.01 s for Lage (about 1.5x). After Turbo populated its cache, warm runs hit 4/4 cached tasks in about 0.50 s; Lage warm runs stayed near 1.49 s on this box.

Short answer: pick Turbo if cold and warm local loops matter and you are fine with Turborepo's cache model. Stay on Lage if you already live in that Microsoft pipeline and your graph is git-backed. No affiliate links in this post.

What I tested

• Machine: 8 vCPU Intel Xeon / 15 GB RAM Linux cloud box, Node 20.19.2 / npm 9.2.0, tested 5 Oct 2026 (about 23:54 to 00:00 IST). Shared box; each cold run deleted .turbo, .lage, package dist folders, and node_modules caches first.
• Fixture: /workspace/bench-turbo-lage/. Workspaces @bench/a, b, c, d. Graph: a has no deps; b and c depend on a; d depends on b and c. Each build script burns a fixed 250k Math.sqrt loop and writes dist/out.txt.
• Tools: turbo 2.11.7 via npx turbo run build (--force for cold); lage 2.17.0 via npx lage build (--no-cache for cold). Lage required a git repo (git init + commit) before it would run.
• Timing: process wall clock via performance.now() around npx. Five interleaved cold pairs. Separate warm series after one seed build per tool.
• Findings: cold wall medians Turbo 1,974 ms / Lage 3,007 ms. Tool-reported cold medians ~1.47 s / ~2.07 s. Turbo warm cache hits (4/4) ~0.50 s median; Lage warm ~1.49 s.
• One surprise: Lage refused to start until the fixture was a git repository. Turbo did not need that.
• Not tested: remote cache (Vercel / Azure), PnP, pnpm/Yarn workspaces, Windows/macOS, affected-only filters on large monorepos, or Nx (covered elsewhere).

Is Turbo faster than Lage on a cold build?

Metric	Turbo 2.11.7	Lage 2.17.0
Cold wall median (5 runs, caches wiped)	1,974 ms	3,007 ms
Tool-reported cold median	~1.47 s	~2.07 s
Warm wall after cache populate	~0.50 s (4/4 cached)	~1.49 s
Packages / graph	4 / diamond	4 / diamond

On this fixture, yes for cold. Turbo's wall clock was about 1.5x lower. The work inside each package was identical, so the gap is orchestrator overhead plus scheduling, not the Math.sqrt loop alone.

For the other monorepo runner decision already on this site, see Turbo vs Nx. Recent Turbo point-release notes live in the Turborepo 2.11.7 post.

Does Turbo's local cache matter more than the cold gap?

For day-to-day loops, yes. Once tasks were cached, Turbo returned in about half a second with 4/4 cache hits. Lage's warm series on this box stayed near 1.5 s. If you restart builds constantly while editing one leaf package, that warm number is what you feel.

Who should not treat warm cache as free: CI agents that wipe the workspace every job, or teams without a remote cache. Then you live on the cold ranking again.

Should you switch from Lage to Turbo?

Situation	My pick
npm/pnpm workspace, want fast local cache hits	Turbo
Already on Turborepo remote cache / Vercel	Stay on Turbo
Pipeline already standardized on Lage + git hashes	Stay on Lage
Need a git repo just to run the task runner	Budget for Lage's git requirement
Comparing against Nx instead of Lage	Read Turbo vs Nx​

Bottom line: 1.97 s versus 3.01 s cold, plus ~0.50 s Turbo cache hits, is the decision pair for me. Who should not switch yet: large Lage shops where remote cache, custom pipelines, and team muscle memory dwarf a one-second cold gap. For install speed around either tool, see pnpm vs npm vs Bun; for bundler choices inside the packages, see Rspack vs webpack and Vite vs Parcel.

How this was made: I built a 4-package diamond workspace, installed Turbo and Lage on the ShopperCove test box, timed interleaved cold builds and warm cache runs, and kept the JSON; the write-up was drafted with AI help and checked against that output.

Sources

• 01turbo.build/repo/docs
• 02npmjs.com/package/turbo
• 03microsoft.github.io/lage/
• 04npmjs.com/package/lage
• 05github.com/vercel/turborepo
• 06github.com/microsoft/lage

Related

• 01shoppercove.com/blog/rolldown-vs-rollup
• 02shoppercove.com/blog/knip-vs-depcheck
• 03shoppercove.com/blog/swc-vs-esbuild-babel