Turbopack in Next.js 16.3: 90% Less Memory, But the Real Story Is AI Coding Is Eating Your RAM

Next.js 16.3 dropped on June 29, 2026. Three numbers from Vercel's release post (nextjs.org/blog/next-16-3-turbopack): Turbopack's dev server now uses up to 90% less memory; the React Compiler's native Rust port lands as an experimental integration with 20-50% compile wins on v0; HMR cold start drops 15% on complex apps. next build also joins next dev in supporting persistent disk cache.

The headline is real. But it isn't the story.

The story is that Turbopack had to ship these changes because the machine you code on in 2026 looks nothing like the one you coded on in 2022. AI coding agents, LSP-driven IDEs, always-on typecheckers, and aggressive linters now share your laptop's RAM with the bundler. Three years ago the bundler won that fight on CPU grounds. Today it loses on memory grounds unless it deliberately gets out of the way.

Vercel said it plainly in the release notes:

"Coding agents, IDEs, typecheckers, and linters all run at dev time, and each consumes a significant chunk of system memory. Over the last three months, the Turbopack team has been committed to reducing its contribution to system memory pressure."

That sentence is the real news. The 90% figure is the receipt.

The Old Trade-Off: Cache More, Pay Less CPU

Turbopack's core design has always been incremental compilation. By caching work it previously did, it avoids recompiling files that haven't changed. The promise: compile time is proportional to the size of your changes, not the size of your route graph.

To hit that promise, the bundler made a deliberate trade-off: cache more results in memory, spend less CPU on every recompile. The math worked. In 2022 and 2023, when the only other thing competing for dev-time RAM was your editor, the math kept working.

Then it stopped working.

An LSP server can hold 1.5–3 GB on a medium-sized TypeScript codebase. A Coding Agent like Claude Code or Cursor's background agents can hold another 1–2 GB while indexing. A tsc --watch plus ESLint daemon adds another half-gig. Add a Vite or Turbopack dev server that grows unboundedly across a long session, and on a 16 GB MacBook you're paging to swap before lunch.

That's the world Turbopack 16.3 was built for.

How Turbopack Actually Freed 90% Memory

The reduction isn't a single trick. It's three things stacking:

1. Compressing internal data structures that previously held full module graphs in memory.
2. Shorter retention windows — don't keep data around longer than necessary.
3. A new eviction ability that flushes cold cache entries back to disk.

The third is the load-bearing one. It leans on the file-system persistence cache that first shipped in Next.js 16.1. With persistence enabled, Turbopack can evict in-memory results because it knows it can reload them from disk on demand. Memory becomes an L1 cache; disk becomes the source of truth.

In 16.3, both options are on by default. The escape hatch is turbopackMemoryEviction, an experimental config flag you can flip off when you're investigating a cache or performance bug.

Vercel is honest about the limits: there's no single reduction percentage that applies to every application. Results depend on the size of your route graph, how much of it was touched, and how long your session ran. "Up to 90%" is the ceiling, not the median. On a small blog you'll see almost nothing; on a large multi-zone app you'll feel it immediately.

This pattern should sound familiar. It's the same architecture database buffer pools have used for thirty years: keep hot pages in memory, evict cold ones, reload on demand. Turbopack's dev server is, for all practical purposes, a small buffer pool for compiled artifacts.

Persistent Disk Cache Now Covers next build

The file-system cache has been speeding up next dev since 16.1. After months of hardening on Vercel's own sites, the same persisted cache is now available for next build.

This matters more than it sounds for CI.

In a CI setup, you can copy the generated .next directory from one run into the next. When the next build starts, Turbopack reads cache entries from disk before compiling anything new. For monorepos with hundreds of routes, the savings on warm caches routinely beat 50%, sometimes more.

It's the same trick ccache has played for C/C++ builds for a decade: ship the intermediate artifacts, don't re-derive them. The build server doesn't need to be smarter; it just needs to remember what it already did.

The flag is turbopackFileSystemCacheForBuild. Enable it in CI. Don't enable it locally without thinking about it — stale caches cause a different class of bug.

Rust React Compiler: The Quiet 50% Win

This is the upgrade that most people will under-react to.

The React Compiler has been stable in Next.js since 16.0 — but only as a Babel transform. Babel runs in Node.js, single-threaded, on the JavaScript event loop. On larger applications, the React Compiler via Babel could slow down builds while waiting for JS execution resources.

The React team recently published a native Rust port of the compiler. Vercel integrated it into Turbopack quickly. On v0 and other large React apps they tested, compile time dropped 20-50%.

To try it:

// next.config.js
module.exports = {
  experimental: {
    reactCompiler: true,
    turbopackRustReactCompiler: true,
  },
};

It's experimental, which means breaking changes are possible. But the bar Vercel is signaling is real: at some point this won't be experimental, and Babel will go away.

HMR, import.meta.glob, and Smaller Runtime

A few smaller wins worth knowing:

• HMR cold start drops 15%+ on complex apps. The biggest fix: collapsing multiple chunk subscriptions into a single one. Less event-loop traffic, faster paint.
• import.meta.glob is now a first-class Turbopack feature, matching Vite's API. The file watcher auto-triggers recompile when matching files are added or removed. Library authors get a portable API across the JS ecosystem.
• Smaller runtime size. Turbopack used to ship code for WASM, workers, and top-level async modules to every route. Now it only ships those features when a route actually needs them. Smaller bundles, faster first paint.

For import.meta.glob specifically:

// Lazy (default) — each value is an async function
const modules = import.meta.glob('../docs/*.md');

// Eager
const modules = import.meta.glob('../docs/*.md', { eager: true });

This won't work on Next.js apps still built with the --webpack flag. If you've been deferring the webpack-to-turbopack migration, this is yet another reason to stop deferring.

What To Do This Week

If you ship Next.js in production:

1. Upgrade to 16.3 today on a non-critical branch. Memory eviction is on by default, so the worst case is "you notice nothing."
2. Enable turbopackFileSystemCacheForBuild in CI first, locally second. Stale local caches will cost you more time than stale CI caches.
3. Try turbopackRustReactCompiler on a large route. If you don't see a 20%+ win, that's a signal your app's compile bottleneck is elsewhere (probably a Babel loader chain).
4. Audit your dev-time memory footprint. Open Activity Monitor / Task Manager during a normal dev session. If Turbopack is using more than ~1.5 GB on a small app, something is off — eviction should clamp it.
5. Plan the webpack exit. With import.meta.glob matching Vite and the Rust React Compiler landing, the last reasons to stay on webpack are shrinking. By 17.x they may be gone.

Turbopack in 16.3 isn't a marketing release. It's the moment Turbopack stops pretending it can have everything in memory and starts behaving like the rest of your dev tooling: cooperative, evictable, willing to give up cache to let a Coding Agent finish indexing your codebase.

That's not a flex. That's survival.