Edge vs Node in production: isolates, cold starts, and the data-locality trap

V8 isolates: what near-zero cold start actually costs

The Edge runtime is not a smaller Node — it is a different execution model. Your code runs in a V8 isolate: a fresh JavaScript context spawned inside an already-running process, the architecture Cloudflare Workers pioneered. Spawning an isolate is allocating a heap and a global object — single-digit milliseconds, often less. A Node lambda cold start, by contrast, is a stack of real work: provision a microVM (~50–200 ms), boot Node itself (~50–100 ms), then require your framework and page graph (50–500 ms, multi-second with heavy dependency trees). That is the honest range behind “edge has ~0 cold starts vs 200–800 ms”: isolates skip the boot, not the physics. Warm invocations are within a few milliseconds of each other on both runtimes — the entire latency argument for edge is the cold path and the geography.

The price is the API surface. An isolate exposes Web APIs only — fetch, Request/Response, URL, crypto.subtle, streams — and none of Node: no fs, no net, no child_process, no native addons. That last one bites hardest: sharp, bcrypt, anything with a .node binary, and classic database drivers with native engines are out — you need WASM builds, HTTP-based serverless drivers, or a different runtime. Dynamic code evaluation (eval, new Function) is banned outright. And bundles are capped — on the order of 1–4 MB compressed depending on plan — because the isolate model only stays cheap if code ships small. Next lets you choose per route segment, which is the whole point: the decision is not app-wide.

// app/api/checkout/route.ts — co-located with the database: stay on Node
export const runtime = 'nodejs';

// app/api/geo-banner/route.ts — data-free, latency-sensitive: edge is free speed
export const runtime = 'edge';

export async function GET(request: Request) {
  const country = request.headers.get('x-vercel-ip-country') ?? 'US';
  return Response.json({ banner: country === 'DE' ? 'eu-promo' : 'default' });
}

The data-locality trap

The numbers that decide edge-vs-node are RTTs, and they are brutal in their asymmetry: same-region under 1–2 ms, cross-US 60–80 ms, transatlantic 80–100 ms, US-to-APAC 180–250 ms. A route’s latency is roughly client→compute RTT + N_sequential × compute→data RTT + work. Node co-located with the database makes the long hop once — the client RTT — and every query after that is sub-millisecond. Edge inverts it: the first hop shrinks to single digits, and every sequential query now pays the full compute→data RTT. One query, you roughly break even. Four sequential queries from a Sydney PoP to a Virginia Postgres is 800+ ms of RTT alone — strictly worse than the setup it replaced, which is exactly the incident in the hook. There is a second, quieter cost: classic pooled TCP database connections do not survive the isolate model, so edge database access goes over HTTP-based serverless drivers — each query carrying HTTP overhead instead of a warm pooled socket.

So edge compute wins in exactly two situations. Compute that touches no data: redirects, geo-personalization from request headers, A/B bucket assignment, verifying a signed token with crypto.subtle — these are pure CPU on the request itself, and running them 10 ms from the user instead of 200 is free speed. Or data that is replicated to where the compute runs: edge KV stores, per-PoP caches, regional read replicas — reads land local, and the geography works for you. Together these two conditions draw a single, non-negotiable line: if your route is not data-free and your data is not replicated to the PoP, edge will make things slower — not faster. Everything else — a checkout flow, a dashboard with N queries, anything transactional against a single-region primary — belongs on Node in the database’s region, where sequential queries cost microseconds and the user pays the long hop exactly once.

Middleware is a tax on every request

Next middleware runs before the cache and the router, on every request the matcher lets through — pages, RSC payload fetches, prefetches, and, with a sloppy matcher, static assets too. That makes its latency a flat tax on the whole site: whatever middleware does is added to every TTFB. The discipline that keeps the tax near zero: middleware does routing decisions, header and cookie rewrites, and local verification of signed tokens — crypto.subtle HMAC or JWT signature checks cost tens of microseconds and touch nothing. What it must never do is talk to a database or fetch your own API: a middleware that calls /api/session to gate routes adds an edge→origin round trip plus a DB query in front of every single page load, doubling TTFB globally — and it is invisible in route-level profiling because the cost lands before the route starts.

// middleware.ts — verify locally, never fetch your own API here
import { NextResponse } from 'next/server';
import { jwtVerify } from 'jose';

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'], // exclude assets or they pay too
};

export async function middleware(req: Request) {
  const token = req.headers.get('cookie')?.match(/__Host-session=([^;]+)/)?.[1];
  if (!token) return NextResponse.redirect(new URL('/login', req.url));
  try {
    await jwtVerify(token, secret); // local signature math: ~0.05 ms, zero IO
    return NextResponse.next();
  } catch {
    return NextResponse.redirect(new URL('/login', req.url));
  }
}