Edge runtime vs Node.js runtime: when to use each in 2026

Edge runtime is faster than Node.js runtime for most marketing sites and APIs. But it has limits. Picking the wrong runtime wastes time and money.

What edge runtime is

Edge runtime runs your code on a V8 isolate close to the user. The isolate starts in under 5ms, executes your function, and shuts down. There is no long-lived server.

Edge runtime providers (Vercel, Cloudflare Workers, Deno Deploy) deploy your code to 200+ regions globally. The user request hits the closest region. TTFB is sub-100ms almost everywhere.

What Node.js runtime is

Node.js runtime runs your code on a long-lived server in a single region. The server starts once, stays up, and handles many requests. Cold start can be 1 to 5 seconds for complex apps.

Node.js supports the full Node.js API: fs, Buffer, native modules, child processes. Most npm packages work without changes.

The edge runtime limits

• No native Node modules (sharp, sqlite, anything that uses C++ bindings).
• No fs or Buffer APIs in the standard way.
• 30-second execution cap on most platforms.
• Limited CPU (typically 50 to 200ms of CPU time per request).
• Limited memory (typically 128 MB).
• No long-lived connections (no WebSocket server).

These limits are real. They are not theoretical. We have hit them on client projects.

The Node.js runtime limits

• Higher TTFB (200 to 500ms in best case, 1 to 5 seconds cold).
• Idle cost stays high regardless of traffic (the server is always on).
• Single region (unless you add a multi-region setup).
• Slower global reads.

The decision framework

### Use edge runtime for

• Marketing sites. Every page is a static or ISR render.
• Auth middleware. JWT validation, rate limiting, redirects.
• Simple APIs. Read-only CRUD, JSON-LD generation, OAuth callbacks.
• Edge-configurable features. A/B testing, feature flags, geo-redirects.
• Anything that benefits from sub-100ms TTFB globally.

### Use Node.js runtime for

• Image processing. Sharp, image-resize, format conversion.
• File uploads. Multipart parsing, virus scanning, S3 uploads.
• Large JSON parsing. Over 1 MB payloads.
• Native modules. Anything that uses C++ bindings.
• WebSocket servers. Long-lived connections.
• Long-running compute. Over 30 seconds.

### Use both

You can mix runtimes in one Next.js app. Middleware is edge by default. Pages and API routes pick the runtime per route:

For an upload API, use runtime nodejs. For a health API, use runtime edge.

This is the pattern we use on most projects. Edge for reads, Node.js for writes.

Common mistakes

### Putting heavy compute on edge

We saw a client put a PDF generation endpoint on edge. It timed out at 30 seconds on large PDFs. Moved to Node.js, problem solved.

### Putting simple APIs on Node.js

We saw a client put a JSON-LD endpoint on Node.js. It served 100 requests per second with 400ms TTFB. Moved to edge, TTFB dropped to 50ms.

### Forgetting the bundle size

Edge functions have a 1 to 4 MB bundle size limit. If you import a heavy library, you will hit the limit. Use tree-shakeable imports.

### Using native modules on edge

Sharp, sqlite, bcrypt are not available on edge. If your API uses any of these, you must use Node.js.

What we use

For our marketing site and most client marketing sites: edge runtime for everything. Sub-100ms TTFB globally. Free tier covers most small sites.

For our analyzer endpoints: edge runtime. The work is HTML parsing and JSON transformation, both fast on edge.

For our internal admin and dashboard: Node.js runtime. Heavy compute, native modules, long-lived sessions.

The decision is per route. We do not pick edge or Node.js for the whole app. We pick per route based on the workload.