For years, the standard advice for CPU-bound work in Node.js has been simple: use worker threads. Offload the heavy computation. Keep the event loop free. It sounds clean. It sounds correct. But according to a detailed technical investigation published by Inngest, the reality of Node.js worker threads is far messier than the documentation suggests — riddled with hidden overhead, serialization costs, and architectural limitations that can silently degrade the very performance they’re supposed to protect.
The findings matter because Node.js is no longer just the runtime powering chat apps and REST APIs. It’s the backbone of serverless functions, AI orchestration pipelines, and background job systems processing millions of tasks daily. When the concurrency model breaks down under real workloads, the consequences ripple outward into latency spikes, stalled queues, and infrastructure costs that balloon without explanation.
Here’s what Inngest’s engineering team discovered: spinning up a Node.js worker thread isn’t cheap. Each new worker thread creates an entirely new V8 isolate — a separate instance of the JavaScript engine with its own heap, garbage collector, and compilation pipeline. That’s not a lightweight green thread. That’s not a goroutine. It’s closer to forking a process, minus the copy-on-write memory optimization that makes fork() tolerable in Unix systems. The team measured startup costs for a single worker thread at several milliseconds, which sounds trivial until you’re trying to process thousands of short-lived tasks per second.
The serialization tax is where things get truly painful. Data passed between the main thread and a worker thread in Node.js must be serialized using the structured clone algorithm — the same mechanism browsers use for postMessage. For small payloads, the cost is negligible. For the kind of data structures common in production systems — large JSON objects, arrays of database records, AI model inputs — serialization and deserialization can dwarf the actual computation time. Inngest’s team found scenarios where the overhead of moving data to a worker exceeded the time the worker spent processing it.
This isn’t a new problem, exactly. But it’s an underappreciated one.
The Node.js documentation does mention SharedArrayBuffer as an alternative to structured cloning, allowing threads to share memory directly. In theory, this eliminates the serialization bottleneck. In practice, SharedArrayBuffer is constrained to raw binary data — fixed-length typed arrays of integers and floats. You can’t share a JavaScript object. You can’t share a string without encoding it. You can’t share anything with a dynamic shape. And coordinating access to shared memory requires Atomics operations that introduce their own complexity, including the risk of deadlocks that JavaScript developers have historically never had to think about.
So the typical Node.js developer faces an ugly choice: pay the serialization tax on every message, or rewrite application logic around low-level binary protocols. Most choose the former. Many don’t realize they’re choosing at all.
Inngest’s analysis goes further, examining how worker threads interact with the event loop under sustained load. The company builds an orchestration engine for serverless and background functions, so their interest isn’t academic — they need to run untrusted or semi-trusted user code alongside their own control plane without one blocking the other. What they found is that even with computation offloaded to workers, the main thread still bears significant coordination overhead. Every postMessage call enqueues a task on the receiving thread’s event loop. Under high throughput, these message-handling callbacks compete with I/O callbacks, timers, and microtasks for execution time. The event loop doesn’t grind to a halt, but it develops a kind of chronic congestion — increased latency across all operations, not just the CPU-bound ones.
The team also documented a subtler issue: memory pressure. Because each worker thread runs its own V8 isolate, memory consumption scales linearly with the number of workers. A pool of eight worker threads doesn’t use eight times the memory of the main thread — the overhead depends on what each isolate loads and allocates — but it’s substantial. In memory-constrained environments like containers with 512MB or 1GB limits, a moderately sized thread pool can push the process toward out-of-memory kills. And V8’s garbage collector runs independently in each isolate, meaning GC pauses can hit different threads at different times, creating unpredictable latency patterns that are difficult to diagnose.
None of this means worker threads are useless. They’re not.
For genuinely CPU-intensive operations — image processing, cryptographic hashing, data compression — worker threads remain the best built-in option Node.js offers. The key qualifier is “built-in.” Inngest’s post makes a compelling implicit argument that the worker thread model is insufficient for the class of problems modern Node.js applications increasingly face: running complex, long-lived, or parallel business logic where the overhead-to-computation ratio makes threads impractical.
The broader Node.js community has been circling this problem for a while. A Node.js official documentation page on worker threads carefully notes that they are “useful for performing CPU-intensive JavaScript operations” but adds that they “do not help much with I/O-intensive work.” What the documentation doesn’t say — and what Inngest’s investigation makes explicit — is that many real-world workloads fall into a gray zone that is neither purely CPU-bound nor purely I/O-bound. A function that fetches data, transforms it, runs some validation logic, and writes results involves both computation and I/O in proportions that shift depending on input size and system state. Worker threads are a blunt instrument for this kind of work.
Alternative approaches exist, and they’re gaining traction. One is to avoid threading entirely and instead use separate processes coordinated through IPC or message queues. This sacrifices shared-memory efficiency but gains process-level isolation, independent crash domains, and compatibility with operating system tools for resource limiting. Node’s built-in cluster module follows this philosophy, though it’s designed for scaling HTTP servers rather than general task parallelism.
Another approach — the one Inngest appears to be investing in — involves moving the execution boundary outside Node.js altogether. By running user-defined functions as discrete steps orchestrated by an external engine, computation can be distributed across processes, containers, or even separate machines without the main thread ever touching the heavy work. It’s an architectural pattern more than a runtime feature, and it sidesteps the worker thread problem by eliminating the need for intra-process parallelism.
The Rust and Go communities have watched Node.js struggle with this from a distance. Go’s goroutines — multiplexed onto OS threads by the runtime scheduler — handle millions of concurrent tasks with minimal overhead and no serialization cost for shared data (protected instead by channels or mutexes). Rust’s Tokio runtime offers similar capabilities with even finer-grained control. These comparisons aren’t entirely fair; Node.js was designed around a single-threaded event loop for good reasons, and that model works extraordinarily well for its original use case of high-concurrency I/O servers. But as Node.js applications take on heavier computational responsibilities — AI inference preprocessing, PDF generation, real-time data transformation — the single-threaded foundation shows its age.
There are efforts to improve the situation within Node.js itself. The node:worker_threads module has seen incremental improvements in recent releases, including better transfer semantics for certain object types via the Transferable interface. Transferring an ArrayBuffer, for example, moves ownership from one thread to another without copying data — a zero-cost operation. But transferability remains limited to a small set of types. The broader JavaScript specification doesn’t provide mechanisms for transferring arbitrary objects, and proposals to change this have moved slowly through TC39.
Meanwhile, the WebAssembly community is experimenting with shared-nothing concurrency models that could eventually influence how Node.js handles parallelism. The Component Model proposal for Wasm envisions composable, sandboxed modules that communicate through well-defined interfaces rather than shared memory. If adopted in Node.js, this could provide a path to safe parallelism without the V8 isolate overhead — but that future is years away at best.
What’s actionable today? Inngest’s findings suggest several practical guidelines. First, avoid creating worker threads on demand for short-lived tasks. The startup cost makes this an anti-pattern. Use a thread pool, and keep it warm. Second, minimize the size of messages passed between threads. Restructure code so that workers receive references or keys rather than full data payloads, fetching what they need independently. Third, measure serialization overhead explicitly. Most APM tools don’t break this out, so you may need custom instrumentation to see it. And fourth, consider whether your workload actually needs threads at all — or whether process-level parallelism, external orchestration, or architectural redesign would serve better.
The JavaScript runtime wars aren’t making this conversation simpler. Deno and Bun, the two most prominent Node.js alternatives, both support worker threads with similar underlying mechanics — V8 isolates in Deno’s case, JavaScriptCore contexts in Bun’s. Bun has touted faster startup times for workers, but the fundamental serialization and memory overhead remain. CloudFlare Workers take a different approach entirely, running each request in a lightweight V8 isolate with aggressive memory limits and no shared state. That model scales beautifully for stateless HTTP handlers but doesn’t generalize to all workloads.
For the companies building infrastructure on top of Node.js — and there are many, from Vercel to Netlify to Inngest itself — the worker thread question is ultimately a question about the boundaries of the runtime. How much work should happen inside a single Node.js process? Where do you draw the line between “this belongs in a thread” and “this belongs in a separate service”? The answer depends on latency requirements, memory budgets, operational complexity tolerance, and the nature of the workload itself. There is no universal answer. But the default assumption — that worker threads are a straightforward solution for CPU-bound work — deserves a lot more scrutiny than it typically gets.
The engineering community tends to treat runtime concurrency primitives as solved problems. They are not. Not in Node.js, and arguably not anywhere. What Inngest’s investigation demonstrates is that the gap between the abstraction — “just use a worker thread” — and the mechanical reality of V8 isolates, structured cloning, and event loop contention is wide enough to swallow your performance budget whole. Understanding that gap isn’t optional for teams running Node.js at scale. It’s the difference between a system that performs and one that mysteriously doesn’t.
WebProNews is an iEntry Publication