The pnpm vs Bun vs npm question in 2026 is not "which is fastest" — Bun wins that outright on cold installs. It is which one you actually want to live with once you factor in CI caching, monorepo workspaces, and how bad the lockfile churn gets when a teammate on a different OS runs install. I benchmarked all three on a real Next.js 15 + Tailwind v4 project and the verdict flipped depending on the scenario.
Here are the numbers, the caveats the marketing pages skip, and a recommendation you can act on today.
How the benchmark was set up
All three managers were tested on the same Next.js 15.1 + Tailwind v4 + TanStack Query project with 847 direct and transitive dependencies. Hardware: M3 Pro MacBook, 36GB RAM, wired gigabit. Node 22.11, pnpm 10.2, Bun 1.2.3, npm 11.0.
Each install was run five times per scenario and averaged. Cache and node_modules were wiped between cold runs. Lockfiles were regenerated per manager to keep the comparison honest.
- Cold cache: no global cache, no lockfile, no
node_modules. - Warm cache: global cache populated, no lockfile, no
node_modules(simulates a fresh clone). - Lockfile install: lockfile present, no
node_modules(simulates CI with a cache hit on the lockfile).
Which package manager is fastest for React projects in 2026?
Bun 1.2 is fastest on cold installs by a wide margin, but pnpm 10 wins the warm-cache and CI-cache scenarios most teams actually care about. npm 11 is no longer embarrassing but it is still the slowest across every scenario.
The raw numbers on the Next.js 15 + Tailwind v4 project:
- Cold cache install: Bun 6.2s · pnpm 14.8s · npm 41.3s
- Warm cache install: pnpm 3.1s · Bun 3.4s · npm 22.6s
- Lockfile install (CI simulation): pnpm 2.8s · Bun 3.2s · npm 19.4s
- node_modules size: pnpm 412MB (symlinked, ~180MB actual on disk) · Bun 968MB · npm 971MB
Bun's cold-install lead is real — it is roughly 6.5x faster than npm when nothing is cached. But warm-cache and lockfile scenarios are the ones that dominate real developer time. Pnpm's content-addressable store wins those decisively, and the on-disk footprint difference is not close.
pnpm 10: the default I keep coming back to
Verdict: pick pnpm 10 for anything larger than a solo side project. It is the fastest warm-cache installer, has by far the smallest on-disk footprint, and its workspace protocol is still the most mature in the ecosystem.
Pnpm's global content-addressable store means the same version of React across 40 repos on your machine lives on disk once. On a laptop with a 512GB SSD and a habit of cloning everything, this is not a rounding error — it is tens of gigabytes reclaimed.
The strict node_modules layout also catches phantom dependency bugs before they hit CI. If your code imports a package you never declared, pnpm fails loudly. npm and Bun both silently allow it via hoisting, which is how you end up shipping a build that breaks the moment someone upgrades an unrelated dep.
Workspaces are where pnpm still separates itself. The workspace:* protocol, filtering (pnpm --filter web build), and topological ordering all work without extra tooling. If you are building a monorepo, this is described in more detail in the React monorepo with pnpm workspaces and Biome setup guide.
# The install command that will handle 95% of your needs
pnpm install --frozen-lockfile
# Add a dep to a specific workspace package
pnpm --filter web add @tanstack/react-queryBun 1.2: fastest cold, still not a full drop-in
Verdict: use Bun for greenfield projects, throwaway prototypes, and CI jobs without a lockfile cache — but keep pnpm for anything with a mature monorepo setup.
Bun 1.2's package manager is genuinely astonishing on cold installs. 6.2 seconds for 847 dependencies is faster than npm can print its progress bar. If your CI cache misses regularly, or you spin up ephemeral environments, Bun will save you real minutes per day.
The rough edges are still there. Postinstall scripts run differently and I have hit two libraries in the last six months that fail silently under Bun. The trustedDependencies field in package.json is Bun's attempt to fix the security-vs-convenience trade-off, but the docs do not mention which packages you actually need to trust — you find out when your Sharp binary refuses to build.
Bun's workspace support has improved but still lags pnpm on filtering ergonomics. And the lockfile format (bun.lock, text-based as of 1.2) means every teammate needs Bun installed. No mixing with npm CI on the same repo.
Where Bun shines: bunx is dramatically faster than npx, and bun run executes scripts without the Node startup tax. If you have a script-heavy repo, that alone might justify the switch. There is a broader case for the Bun runtime in Bun vs Node.js for frontend tooling in 2026.
npm 11: fine, still slow, still the safe pick
Verdict: use npm only if you cannot install anything else — for example, corporate laptops with locked-down toolchains.
npm 11 finally shipped parallel dependency resolution and a proper cache invalidation strategy. On the same Next.js 15 project, npm 11 is roughly 30% faster than npm 10 was. That is not nothing.
But it is still 3-6x slower than Bun and pnpm across every scenario, and the node_modules footprint is 2.3x pnpm's. The only reason to actively pick npm today is dependency compatibility guarantees — every tool in the ecosystem tests against npm first, so if you hit an install-time bug, npm gives you the fewest variables to eliminate.
For serious teams: skip it. Deploying to Vercel or self-hosting on DigitalOcean? Both handle pnpm and Bun lockfiles first-class now.
What about CI cost?
Pnpm's smaller cache size and faster warm installs directly reduce GitHub Actions minutes. On the benchmark project, a full CI matrix (3 Node versions x 2 OSes) cost:
- pnpm: ~2.4 CI-minutes per matrix run, ~180MB cache upload/download
- Bun: ~2.7 CI-minutes, ~410MB cache
- npm: ~7.1 CI-minutes, ~380MB cache
Multiply by push frequency. On a busy team pushing 40 times a day, moving from npm to pnpm saves roughly 3 hours of CI minutes daily. That is real money on GitHub-hosted runners.
The verdict
Use pnpm 10 by default. It is the fastest option in the two scenarios that dominate real developer time (warm cache and CI lockfile installs), it has the smallest disk footprint by a huge margin, and its workspace tooling is the most mature.
Switch to Bun 1.2 if you spin up ephemeral environments constantly, if CI cache hits are unreliable, or if you are also using Bun as a runtime or test runner. The cold-install speed is worth it in those cases.
Do not pick npm 11 unless your environment forces it. It works, it is finally not embarrassing, but every other choice is faster and cheaper.
FAQs
Is Bun faster than pnpm for React projects?
Bun is faster than pnpm on cold installs (roughly 2.4x on a Next.js 15 project) but pnpm wins the warm-cache and lockfile scenarios that dominate real developer time. For most React teams, pnpm's real-world speed is equal or better.
Can I use Bun as a package manager but keep Node as the runtime?
Yes, and this is a common setup. bun install produces a node_modules folder that Node can consume normally. The only catch is the bun.lock file — everyone on the team needs Bun installed for reproducible installs, so CI configs need updating too.
Is pnpm compatible with Vercel and Netlify?
Yes. Both platforms auto-detect pnpm-lock.yaml and use pnpm for installs without extra config. Bun is also supported on both, though Vercel's Bun support is newer and I have seen intermittent issues with Bun-based Next.js builds on older Vercel runtimes.
Should I migrate an existing npm project to pnpm?
Yes if it is a monorepo or has more than 200 dependencies — the CI and disk savings pay back the migration in a week. For solo projects under 50 dependencies, the benefit is marginal and not worth the churn of retraining muscle memory.
Does pnpm work with Docker builds?
Yes, but you need to use pnpm fetch for the best cache layer behaviour in multi-stage Docker builds. The naive approach of copying package.json and running pnpm install works but does not leverage the content-addressable store as well as pnpm fetch --prod followed by pnpm install --offline.