Every package manager has a moment where you just wait. You add one dependency, or you pull a branch and run install, and there's a beat where the terminal sits there doing file I/O while you tab away. pnpm already made that beat shorter than most, with its content-addressable store and hard-linked node_modules. But it was still a Node.js program, paying the Node startup cost and pushing tens of thousands of file operations through a single JavaScript runtime.
That's the thing that's changing. pnpm v12 takes the part of pnpm that does the heavy lifting, fetching and linking packages, and rewrites it in Rust. It's the same move TypeScript just made with Go, aimed at a different bottleneck. And like that one, the interesting detail is how little is supposed to change for you.
What pnpm v12 actually is
pnpm v12 is the same pnpm you already use, ported to Rust. pnpm has always been TypeScript running on Node.js, and the Rust work lives under the codename pacquet, whose repo describes it in one line: "The official pnpm rewrite in Rust." The key word there is rewrite, not reimagining. It's a port. The flags, defaults, error codes, lockfile format, and node_modules layout are all meant to match pnpm exactly.
Zoltan Kochan, pnpm's creator, put it plainly when the v12 plan came together: "v12 should behave the same as v11, the biggest change will be the full rewrite to Rust." That's the frame to hold onto. This is a performance release wearing a major version number, not a redesign of how pnpm works.
pacquet started as a separate experimental repo and moved into the main pnpm monorepo in May 2026, so the TypeScript and Rust versions now evolve side by side. The eventual goal is for the Rust engine to be what you run.
Why Rust
The motivation isn't abstract. Two things were capping how fast a Node-based pnpm could go.
The first is startup cost. Every invocation booted a Node.js runtime before it did any work. pnpm v12 ships as native per-platform binaries with no Node.js launcher, so a command pays no runtime bootstrap cost at all. On a fast, cached install where the actual work is milliseconds, that bootstrap was a real fraction of the wall-clock time.
The second is the file I/O itself. A cold install on a large monorepo is really a lot of filesystem operations: fetching tarballs, unpacking them into the store, and hard-linking thousands of files into place. Running all of that through a single JavaScript thread leaves throughput on the table. Rust handles that fan-out natively, without the runtime sitting in the middle of every syscall.
There's a softer reason too, and it's the same one that's driving the broader trend: the tooling to do this kind of rewrite has gotten dramatically better, and AI-assisted porting made a 1:1 translation of a large codebase far more tractable than it would have been a few years ago.
How much faster is it
pnpm publishes a benchmark suite comparing v11 against the Rust engine directly. As of this writing (July 2026), here's what it shows:
| Scenario | pnpm v11 | pnpm (Rust) |
|---|---|---|
| Everything warm (repeat install) | 381 ms | 12 ms |
| node_modules present, no cache | 460 ms | 40 ms |
| Clean install (nothing cached) | 6.5 s | 2.2 s |
The warm case is everything already in place, so the install just re-verifies the tree, which is what happens on every CI job. That drops from 381ms to 12ms, roughly a 30x difference, and it's the number you'll feel most, because it runs constantly. The colder cases improve less dramatically but still meaningfully: a fully clean install with nothing cached goes from 6.5s to 2.2s, about 3x.
Treat these as pnpm's own numbers on pnpm's own hardware, and expect your mileage to vary with disk speed and project size. But the direction is not subtle, and the team's claim is that the Rust engine is faster than v11 in every scenario they measured.
It's already rolling out, incrementally
Here's the part that's easy to get wrong: pnpm v12 isn't a big-bang release. The Rust engine has been landing piece by piece through the v11 line, opt-in first.
- pnpm 11.2 let you opt into pacquet as the install backend for materialization only. Rust did the fetch and link, while pnpm still resolved dependencies and wrote the lockfile.
- pnpm 11.7 went further: a standard install could be delegated to pacquet end-to-end, with resolution, lockfile write, and linking all in a single Rust pass.
-
pnpm 11.10 added
pnpm self-update next-12, so you can pull the v12 line and try the Rust binary directly.
In v12, the Rust engine for fetching and linking becomes the default rather than an opt-in. The official roadmap then works outward from there: first the headless frozen-lockfile installer, then full dependency resolution (add, update, remove, catalogs, overrides, peers), and finally the remaining commands like run, store, and publish. So even after v12 ships, parts of pnpm will still run through the TypeScript implementation for a while. The lockfile is what lets the two halves cooperate.
What changes for users
The honest answer is: not much, on purpose. Same CLI, same lockfile, same node_modules. The whole point of a 1:1 port is that your muscle memory and your CI scripts keep working.
The breaking changes slated for v12 are deliberately small: removing some old migration code for git-hosted tarballs, rejecting unscoped auth settings, and deprecating the $ syntax in overrides in favor of catalogs. If none of those describe your setup, a v12 upgrade should be close to a no-op.
The one thing worth checking is feature parity during the transition. Because the Rust engine is being ported incrementally, some newer or niche capabilities may lag the TypeScript version at any given moment. If your install depends on something specific (a particular linker mode, lockfile-verification settings, or pnpm deploy), test the bump in an isolated git worktree before you flip it on in CI. This is moving quickly, so the right list of gaps is whatever the roadmap says on the day you upgrade.
The bigger picture
pnpm is not doing this alone. The last few years have quietly rebuilt the JavaScript toolchain's foundations in native languages: Biome for linting and formatting, Oxc for parsing and transforming, Rolldown and Turbopack for bundling. TypeScript's compiler went to Go. Deno is Rust from the ground up. (Bun is the odd one out: it's written in Zig, not Rust, so don't lump it into the "everything's Rust now" story.)
There's a competitive angle underneath it, too. Bun and Deno both ship as single fast binaries with package management built in, and a chunk of their appeal is exactly that no-runtime-bootstrap speed. A native-binary pnpm with no Node launcher closes that gap while keeping the thing that makes pnpm pnpm: the strict, content-addressable store and the non-flat node_modules that catches phantom dependencies.
Should you care yet
If you're waiting for a stable release: keep waiting, but not for long. As of mid-July 2026, v12 is in alpha. The latest tag is v12.0.0-alpha.12, and the stable line is still v11.13.0. This is not something to point production CI at today.
But if you want to feel the difference now, you already can. Run pnpm self-update next-12 on a branch, or opt into the pacquet backend on your current v11, and watch a warm install that used to take a beat return before you've finished reading the command. The type of release this is, where the language underneath gets an order of magnitude faster while everything on top stays exactly where you left it, is a rare and good one. pnpm was already the fast package manager. It's about to stop being one you ever wait on.
Top comments (1)
How will the Rust rewrite impact pnpm's performance, especially for large monorepos? I've had issues with wait times in the past and I'm curious to hear more.