Edge runtimes in 2026: when they’re worth it, when they’re not
Edge is great for redirects, auth middleware, and globally-replicated reads. It is wrong for most database work, CPU-heavy routes, and long-lived connections. The decision tree I actually use.
Two years ago every Next.js project I touched was setting export const runtime = 'edge' on every route by reflex. Vercel pushed it, the discourse pushed it, the perf numbers looked great in the demo. In 2026 I have walked most of those decisions back. Edge runtimes are still the right call for a specific set of workloads, and absolutely wrong for the rest. Here is the decision tree I actually use.
What edge actually buys you
Edge functions run on a worker (V8 isolate, not a container) in a point of presence close to the user. The startup cost is near zero, the geographic distance to the user is small, and time-to-first-byte drops to under 100ms in most regions. That is the win. Everything else (cost, scaling story, deployment story) is comparable to serverless on a good day.
When edge is the right call
Use edge for: redirects, A/B test bucketing, geolocation-based responses, auth middleware, request rewriting, anything that runs before the page and finishes in under 50ms. These are the workloads edge was built for. They have small payloads, no database, no heavy compute, and they benefit linearly from being close to the user.
I also use edge for read-heavy API routes that hit a globally replicated KV store (Cloudflare KV, Upstash, Vercel Edge Config). The whole request loop stays inside the worker, no cross-region database hop, no cold start, sub-millisecond reads. This is the rare case where edge feels magical.
When edge is the wrong call
Most database access. Your Postgres instance lives in one region. If your edge function in Singapore has to talk to your database in Virginia, every query crosses the Pacific twice. The latency you saved on the first byte gets eaten by every database round trip, and you end up slower than a regular serverless function in the same region as the database.
Anything CPU-heavy. Edge runtimes cap CPU per request (usually 30 to 50ms), and they do not have Node's full standard library. Image processing, PDF generation, ML inference, anything that uses a Node-only package (most of npm): not edge.
Long-lived connections. Edge workers are short-lived isolates. WebSockets, SSE streams that run for minutes, background polling: all happier on a real server.
The decision in one paragraph
Edge for small, stateless, latency-sensitive work that touches no regional database. Serverless or a real server for everything else. The mistake people make (and the one I made for a year) is treating edge as a global upgrade to serverless. It is not. It is a different runtime with a different shape, and you pick it for specific reasons, not by default.
The boring truth
Most apps in 2026 do not need edge. They need a single fast region next to the database, a CDN in front of static assets, and decent cache headers on the API responses. That stack handles 95% of the web at a tenth of the complexity. Reach for edge when the workload actually fits it, and not before.