pnpm vs npm vs Yarn vs Bun: 2026 Speed Test

Choosing between pnpm vs npm vs Yarn vs Bun in 2026 comes down to three trade-offs: Bun is the fastest installer, pnpm is the most disk-efficient and the best fit for monorepos, npm is the zero-risk default that ships with Node, and Yarn Berry is the specialist choice for teams that need Plug'n'Play or strict workspace protocols. For most teams starting fresh today, pnpm is the best all-round answer; for solo projects where install speed dominates, Bun wins.

What makes this decision harder than it looks is that almost every comparison benchmarks the same scenario — a cold install with an empty cache — which is the one your CI pipeline is specifically configured to avoid. The numbers that matter are warm installs, lockfile-only installs, monorepo filtering, and how well each tool behaves inside a Docker layer.

This guide covers real speed and disk differences, then gives a decision matrix by situation rather than a single winner.

Key Takeaways

• Bun leads raw cold-install speed, commonly 5–20x faster than npm on the same project, and up to 30x in the most favourable cases.
• pnpm's content-addressable store keeps one copy of each package version on disk and hard-links it into projects — a developer with 10 projects typically saves 15–40 GB.
• pnpm and Yarn Berry both land around 2–3x faster than npm; pnpm reached 92% retention in State of JS versus Yarn's 65%.
• npm still holds roughly 62% reported usage among professional developers in the Stack Overflow survey — dominance in absolute numbers, not in satisfaction.
• Bun's installer is fast but uses a conventional node_modules layout, so its disk usage is comparable to Yarn 4 rather than to pnpm.

Which package manager installs fastest?

Bun is the fastest for cold installs, typically 5–20x faster than npm on the same dependency tree. pnpm and Yarn Berry sit in the middle at roughly 2–3x npm's speed, and npm is the slowest because it downloads and copies every dependency into each project's node_modules separately instead of linking from a shared store.

But cold-install speed is the least representative benchmark in the entire category. Here is what the four look like across the scenarios you actually hit:

Two practical notes that change the ranking in real pipelines:

• In CI with a warm cache, the spread compresses considerably. If your pipeline restores ~/.npm or the pnpm store between runs, npm's disadvantage shrinks from "several minutes" to "tens of seconds."
• In Docker, pnpm's hard-link model needs the store mounted correctly or you lose the benefit entirely and end up copying anyway. This trips up more teams than any raw benchmark.

Why does pnpm save so much disk space?

pnpm uses a content-addressable store: each package version is downloaded once, stored in a global location, and hard-linked into every project that needs it. npm copies the full dependency tree into each project separately, so ten projects sharing React means ten physical copies. In practice, a developer with 10 active projects saves 15–40 GB by switching to pnpm.

That number sounds like a laptop-storage argument, but the real payoff is speed. A hard link is a filesystem operation measured in microseconds; copying thousands of small files is I/O-bound and, on Windows especially, brutally slow. pnpm's disk model and its warm-install speed are the same optimization viewed from two angles.

pnpm's strict layout has a second, underrated benefit: it does not flatten node_modules. Your code can only import packages you actually declared as dependencies. That catches phantom-dependency bugs — the ones where your app works locally and explodes in production because a transitive dependency quietly disappeared in a minor version bump.

Bun takes the opposite approach. It is blisteringly fast on install but uses a conventional layout, so it does not deliver pnpm's disk savings or its strictness. If your primary pain is disk and correctness, pnpm; if it is wall-clock install time, Bun.

What do the adoption numbers actually say?

The survey data splits cleanly into "what people use" and "what people would use again," and the two tell different stories. State of JS put pnpm at 92% retention against Yarn's 65% — pnpm has passed Yarn in retention two years running. Meanwhile Stack Overflow's developer survey put npm at about 62% usage among professionals, with Yarn at 18%.

Bun's signal is different again: its interest score of 81% is the highest ever recorded in the package-manager category. High interest and moderate usage is the classic profile of a tool people want to adopt but have not yet trusted with production.

Read together, the picture is straightforward:

• npm wins on inertia. It ships with Node, so it is the path of least resistance.
• pnpm wins on satisfaction. People who adopt it do not go back.
• Yarn is in slow decline. Berry's Plug'n'Play is technically excellent but its migration cost turned into an adoption ceiling.
• Bun has the enthusiasm but is still buying trust, especially for teams unwilling to adopt its runtime.

The same dynamic played out in Python, where uv's speed advantage collapsed a decade-old tooling debate in about a year — we covered that in uv vs Poetry vs pip. Package managers turn out to be unusually easy to switch, because the migration is a lockfile and a CI line, not a rewrite.

Migration: what it actually costs

Switching package managers is one of the cheapest wins available in a JavaScript codebase, which is why it is worth doing rather than debating. The npm-to-pnpm path is the simplest:

# 1. Install pnpm (Corepack ships with Node)
corepack enable pnpm

# 2. Import the existing lockfile, preserving resolved versions
pnpm import          # reads package-lock.json -> pnpm-lock.yaml

# 3. Clean install and verify
rm -rf node_modules package-lock.json
pnpm install
pnpm test

# 4. Pin the version so CI and teammates match exactly
pnpm config set package-manager-strict true

Add the packageManager field to package.json so Corepack enforces the same version everywhere:

{
  "packageManager": "[email protected]"
}

Three gotchas worth knowing before you start:

1. Phantom dependencies will surface. pnpm's strict layout breaks imports of packages you never declared. This is pnpm reporting a pre-existing bug, not creating one — but it does mean the migration is not always a five-minute job.
2. Some postinstall scripts assume a flat node_modules. Older native modules and a few build tools do this. node-linker=hoisted in .npmrc is the escape hatch.
3. Your Dockerfile needs updating. Mount the pnpm store as a cache layer or you will lose the speed benefit inside containers.

For Bun, the migration is even shorter (bun install reads package.json directly), but verify that every native dependency in your tree compiles — that is where Bun adoption usually stalls. Our Bun vs Node.js vs Deno comparison covers where the runtime is and is not production-ready.

Which one should you choose?

A clear recommendation by situation, no hedging:

• Team project or monorepo → pnpm. Best balance of speed, disk efficiency, workspace tooling, and correctness. This is the default recommendation for most readers.
• Solo project, speed above all → Bun. Fastest installs by a wide margin, and if you also adopt the runtime you replace your bundler and test runner too.
• Inherited legacy codebase → npm. Zero migration risk, universal CI support, and nobody has to learn anything. Switching a codebase nobody wants to touch is not a good use of a sprint.
• Existing Yarn Berry setup with Plug'n'Play working → stay on Yarn. It is excellent when already configured; migrating away buys you little.

If you are on npm today with no strong constraint, moving to pnpm is the single highest-return tooling change available. It takes an afternoon and pays back on every install for the life of the project.

Frequently asked questions

Is pnpm faster than npm? Yes, typically 2–3x faster on cold installs and considerably more on warm ones, because pnpm hard-links packages from a global content-addressable store instead of copying every dependency into each project's node_modules.

Is Bun faster than pnpm? For cold installs, yes — Bun is usually the fastest of the four, often 5–20x faster than npm where pnpm sits around 2–3x. pnpm can match or beat it on warm installs thanks to hard-linking, and pnpm uses far less disk.

How much disk space does pnpm save? A developer with around 10 active projects typically saves 15–40 GB. The saving scales with how many projects share dependency versions, so monorepos and machines with many client projects benefit most.

Can I use Bun's package manager without Bun's runtime? Yes. bun install works as a drop-in installer for projects that run on Node, producing a standard node_modules tree. This is the lowest-risk way to try Bun, since you keep your existing runtime and only change the install step.

Is Yarn still worth using in 2026? Yarn Berry remains technically strong, particularly Plug'n'Play and its workspace protocols, but its retention has fallen behind pnpm (65% versus 92%). If you already run it successfully, stay; if you are choosing fresh, pnpm is the simpler upgrade path from npm.

Which package manager should I use for a monorepo? pnpm. Its workspace filtering, strict dependency isolation, and disk model are all designed for exactly this case. Yarn Berry is a close second if you need Plug'n'Play specifically.

The bottom line

The 2026 package manager landscape has a clear shape: npm for inertia, pnpm for teams, Bun for speed, Yarn for existing investments. The cold-install benchmarks everyone quotes flatter Bun and understate pnpm, because the scenario they measure is the one CI caching is designed to eliminate.

Our verdict: pnpm is the right default for most teams, and the migration from npm is genuinely an afternoon's work. Bun is the right call when raw install speed is the constraint you feel daily and your dependency tree is free of awkward native modules.

Once your installs are fast, the next bottleneck is usually your test suite — our Vitest vs Jest comparison covers where the rest of your CI minutes are going, and Cloudflare Workers vs Vercel Edge Functions covers where they end up deployed.

Pick one, commit it to packageManager, and stop thinking about it.