An edge runtime and Node both run JavaScript, which makes them look interchangeable and is the source of most of the pain. They are not interchangeable. Node is a full server runtime with filesystem access, native module support, and a large standard library built over two decades. An edge runtime is a lightweight isolate implementing web platform APIs, optimized to start in milliseconds and run in many locations at once.
Choosing between them is a question about your workload, and getting it wrong usually surfaces halfway through a migration.
What changed in 2026
- Node compatibility layers improved substantially. Edge platforms shipped shims for more of the Node API surface, which widened the set of libraries that work without modification.
- The hybrid pattern became standard. Rather than choosing one, frameworks made it routine to run some routes at the edge and others on a full runtime in the same application.
- Cold start improved for traditional serverless too. The gap narrowed as container-based functions got faster to start, which weakened one of the edge's headline advantages.
- Database proximity became the real constraint. Running compute near the user helps little when every request travels to a single-region database, and this got recognized as the dominant design problem.
What you give up
| Capability |
Node |
Edge runtime |
| Filesystem access |
Full |
None or heavily restricted |
| Native modules |
Supported |
Not supported |
| Long-running processes |
Yes |
No; per-request execution with time limits |
| CPU-heavy work |
Fine |
Constrained by execution limits |
| Full standard library |
Yes |
Web standard APIs plus partial compatibility |
| Cold start |
Hundreds of milliseconds or more |
Single-digit milliseconds typically |
| Geographic distribution |
Deploy per region |
Runs in many locations by default |
| Memory available |
Configurable, generous |
Tighter limits |
The filesystem absence is the one that breaks the most libraries, often indirectly — a package that reads a configuration file at startup, or a template engine that loads from disk. Native bindings are the second, and they fail unambiguously rather than subtly, which is at least easier to diagnose.
When the edge is genuinely right
Three workload shapes fit well. Request modification — auth checks, header rewriting, redirects, A/B assignment — where the work is small and the latency saving is proportionally large. Personalization at the boundary, where you need a fast decision before serving cached content. And geographically distributed read paths where data is replicated or cached near the user.
The shape that fits badly is anything where the request does real work against a centralized database. Compute at the edge and data in one region means the request crosses the network anyway, and you have added a hop rather than removed one. If your database is not distributed, the edge advantage largely evaporates.
The pragmatic answer for most applications is hybrid: middleware and lightweight routes at the edge, everything else on a runtime with full capability. That is now well supported rather than exotic. For runtime alternatives beyond these two, Bun vs Deno vs Node covers the fuller landscape.
Common mistakes
- Assuming Node code runs unmodified. Compatibility layers help; they do not make an edge runtime into Node.
- Ignoring database location. Edge compute with a single-region database frequently performs worse than regional compute next to the same database.
- Hitting CPU limits at scale. Work that fits comfortably in testing can exceed limits under production input sizes.
- Not auditing dependencies first. A transitive dependency using a native module will block deployment.
- Choosing the edge for cold start alone. Provisioned concurrency and faster container starts address that on traditional runtimes too.
FAQ
Can I use an ORM at the edge?
Some support it via HTTP-based drivers designed for the constraint. Traditional TCP-connection drivers frequently do not work, so check your specific data layer.
How do I know if a dependency will work?
Check whether it uses filesystem access, native bindings, or Node-specific internals. Building against the edge target in CI catches most cases early.
Is edge cheaper?
Pricing models differ enough that it depends on your traffic shape. Per-request pricing can be cheaper for spiky, lightweight workloads and more expensive for sustained heavy use.
Should I move an existing application to the edge?
Rarely wholesale. Move the routes that benefit and leave the rest, which is what the hybrid pattern exists for.
Where to go next
For the wider runtime comparison, read Bun vs Deno vs Node and Deno vs Node. For another sandboxed execution model, WASM component model explained.