Vercel Edge Functions

The core bet: an isolate, not a container

Every serverless platform has to answer one question: what unit of isolation runs your code? Traditional serverless (AWS Lambda, and Vercel’s own Node.js Serverless Functions) gives each function a container or micro-VM with a full Node.js runtime inside. That is powerful — you get the entire Node API, npm, the filesystem, native modules — but it is heavy: spinning up a fresh instance means booting a sandbox and a language runtime, which is where cold starts of hundreds of milliseconds come from.

Edge Functions make the opposite bet. Instead of a container per function, many functions share a single V8 process and each runs inside its own isolate — the same mechanism that keeps browser tabs from reading each other’s memory. An isolate is cheap to create (sub-millisecond) and cheap to keep around, so one server can host thousands of them. The trade is that an isolate is not a Node process: there is no container, no filesystem, no native addons — just a fast, sandboxed JavaScript/Wasm environment with web-standard APIs. Understanding that substitution explains every capability and every restriction that follows.

Where the code runs: the region vs the edge

A normal Vercel Serverless Function executes in one region you choose (say, Washington, DC). A user in Sydney who triggers it sends their request across the Pacific, waits for the function to run, and waits for the response to come back — two ocean crossings before a byte of useful work. Edge Functions instead execute in whichever of Vercel’s many edge locations is closest to the user. The Sydney user is served from Sydney.

This is why the flagship use cases for edge are things that touch every request and benefit from being physically near the user: rewriting a URL, checking an auth cookie, choosing an A/B bucket, injecting a geolocation header, redirecting by country. For those, shaving a round trip is a real, felt improvement. But ‘closest to the user’ is only an advantage if the work can actually complete near the user. If your handler has to query a Postgres database that lives in Washington, running the handler in Sydney just moves the long trip from the browser to the backend — you have not removed it. The lab later in this article makes that failure mode visible.

The Edge Runtime is web-standard, not Node

The single most common source of confusion is treating the Edge Runtime as ‘Node, but faster.’ It is not Node at all. It is a runtime built on web-platform APIs: fetch, Request, Response, URL, Headers, ReadableStream, crypto.subtle, TextEncoder, and the like — the same globals you would use in a browser or a Web Worker.

What is absent is everything Node-specific. There is no fs, no net, no child_process, no Buffer-first world (you use Uint8Array), and no arbitrary native npm modules that shell out to C. Libraries that assume Node — a Postgres driver that opens a raw TCP socket, an SDK that reads the filesystem — simply will not run. This is why database access from the edge typically goes through an HTTP-based data layer (a serverless driver that speaks HTTP, a data proxy, or a service like a REST/GraphQL API) rather than a classic TCP connection pool. Choosing the edge is really choosing this narrower, web-standard API surface on purpose.

Cold starts: the problem the isolate model deletes

Cold starts are the tax you pay when a request arrives and no warm instance is available: the platform must create one before your code can run. On a container-based runtime that means booting a sandbox and a language runtime, commonly tens to hundreds of milliseconds, occasionally worse for heavy dependency graphs.

Isolates largely dissolve this problem. Creating a fresh V8 isolate is a sub-millisecond operation because there is no OS process to fork and no runtime to boot — the V8 engine is already running and simply hands your code a new sandboxed context. The practical result is that Edge Functions have effectively negligible cold starts, which is a genuine reason to prefer them for latency-sensitive, spiky, or globally distributed traffic where a container runtime’s cold path would show up in your p95. It is not magic — the code and its imports still have to be evaluated — but the multi-hundred-millisecond ‘boot a container’ penalty is gone, and that is exactly the penalty the interactive lab lets you toggle on for the origin case.

Middleware: the killer app for the edge

If you use only one thing at the edge, it will probably be middleware. Vercel’s Middleware runs on the Edge Runtime and sits in front of your routes: it sees every matching request before it reaches a page or an API route, and it can rewrite the URL, redirect, add or read cookies and headers, or short-circuit with a response of its own.

Because it runs on every request and runs near the user, middleware is the natural home for cross-cutting concerns: authentication and authorization gates (bounce an unauthenticated user before you pay to render anything), internationalization and geo-based routing, feature flags and A/B bucketing, bot filtering, and setting the request context the rest of your app reads. The discipline that keeps middleware fast is to keep it thin: it runs on the hot path for literally every request it matches, so a slow middleware taxes your entire site. Read a cookie, make a routing decision, attach a header — do not fetch three services and render a template. Heavy work belongs downstream in a function or a page, not in the gate everyone passes through.

Streaming and the user-perceived-speed win

Edge Functions can return a ReadableStream, and combined with React Server Components and streaming SSR this unlocks a second kind of speed: not just a shorter round trip, but a faster first paint. Instead of computing an entire HTML page and sending it in one shot, the edge can start flushing the shell and the above-the-fold content immediately and stream the rest as it becomes ready.

This matters because latency is partly a perception game. A page that shows meaningful content in 200 ms and finishes at 900 ms feels dramatically faster than one that shows nothing until 700 ms and finishes at 800 ms, even though the second technically completes sooner. Running the streaming layer at the edge, close to the user, tightens the loop on every chunk. It also pairs well with AI and LLM responses, which are token streams by nature: an edge function can proxy and forward a model’s stream to the browser with minimal buffering, so tokens appear as they are generated rather than after the whole completion lands.

Geolocation and personalization at the door

Because an Edge Function runs at a specific physical location and sees the raw request, Vercel can hand it geolocation data — country, region, city, approximate coordinates — without a lookup service. That turns a class of personalization that used to require a client-side round trip or a third-party API into a synchronous, zero-extra-latency decision made before the page is even chosen.

The pattern is powerful precisely because it happens at the door: you can redirect European visitors to a GDPR-compliant variant, show prices in the local currency, gate a feature by region for a staged rollout, or serve a country-specific homepage — all decided at the edge, all before any origin work. The caution is the same one that applies to all edge personalization: personalizing a response makes it harder to cache. A response that varies by country, user segment, or A/B bucket cannot be a single shared cache entry, so you trade cache hit rate for relevance. The art is personalizing on a small, bounded set of dimensions (a handful of countries, two A/B buckets) rather than on something high-cardinality that shatters the cache into per-user fragments.

The limits that actually bite

The isolate model buys speed by taking things away, and the restrictions are not footnotes — they decide whether the edge is viable for a given handler. The ones that bite in practice:

Read together, these say the same thing in five ways: an Edge Function should be small, fast, and stateless. It is a smart, distributed gatekeeper and router, not a place to do a big database join, resize an image, or run a long-lived job. When a handler bumps into these walls, the answer is usually not to fight the edge — it is to move that handler to a regional Node function and keep the edge for the thin, latency-sensitive layer.

Edge Functions vs Node Serverless Functions

Vercel offers both, and the choice is per-route, not per-project — you mix them freely. The decision is a straight trade of reach and speed against power and compatibility.

Reach for a Node Serverless Function when the handler needs the Node ecosystem: a traditional database driver with a connection pool, a library that assumes Node APIs, heavier compute, larger dependencies, or longer execution. It runs in one region and eats a real cold start, but it can do essentially anything a Node server can.

Reach for an Edge Function when the handler is thin, latency-sensitive, and web-standard: middleware, auth checks, redirects, geolocation, lightweight personalization, streaming proxies, simple API endpoints that mostly call other HTTP services. A useful rule of thumb: if the handler’s dominant cost is a call back to a single-region database, the edge buys you little and Node is simpler; if its dominant cost is the network distance to the user and the work itself is light, the edge wins.

See it: the edge-vs-origin latency lab

Theory only goes so far. The whole pitch for edge compute is a latency number, so make it tangible: below, every request lands at a random spot on the map. In Edge mode it is served by the nearest of eight points of presence; in Single Origin mode it must travel to one region (us-east-1) no matter where the user is. Fire single requests or a burst of 25 and watch how the median and p95 round-trip times diverge — especially for users far from the origin, and especially once you enable the cold-start penalty.

The lesson the simulator makes obvious: edge doesn’t make any single request dramatically faster for a user who is already next to your origin — it makes the tail faster for everyone else. The further your users are spread from one region, the bigger the p95 win. That is exactly the workload edge functions exist for, and exactly why they are wasted on a database-heavy request that has to call back to that one region anyway.

Vercel Edge vs Cloudflare Workers

Cloudflare Workers is the platform Vercel Edge Functions is most often confused with, and for good reason: both run V8 isolates on a global network with near-zero cold starts and a web-standard API. The core execution model is genuinely similar. The differences are about ecosystem and surrounding platform, not about isolates.

Workers is a general-purpose edge compute platform with its own rich primitive set — KV, Durable Objects, R2, Queues, D1 — and you build directly on it. Vercel Edge Functions are tightly integrated into the Vercel and Next.js developer experience: same repository, same git push deploy, automatic wiring to your framework’s middleware and routing, preview deployments, and Vercel’s own storage and analytics. If you live in Next.js and want the edge to be a seamless part of your app’s deploy, Vercel is the smoother path. If you want a standalone, storage-rich edge platform independent of any one framework, Workers exposes more raw edge primitives. It is less ‘which isolate is faster’ and more ‘which platform do you want to build your whole app inside.’

Vercel Edge vs AWS Lambda@Edge and CloudFront Functions

AWS answers the same ‘run code at the CDN’ need with two products, and the contrast sharpens what Vercel is. CloudFront Functions are extremely lightweight JavaScript that run at the edge for very short, simple request/response manipulations — header rewrites, redirects, basic normalization — with tight CPU and no network access. Lambda@Edge is heavier: full Lambda functions (Node or Python) triggered at CloudFront edges, able to do more but with real cold starts and more operational weight.

Vercel Edge Functions sit in a sweet spot between those two: more capable than a CloudFront Function (real fetch, streaming, richer logic) but far lighter and faster-starting than Lambda@Edge, and dramatically simpler to deploy because they ship with your app instead of being wired into a CloudFront distribution by hand. The AWS options give you more control and fit an AWS-centric architecture; the Vercel option gives you an integrated, framework-native edge with almost no configuration. As with Workers, the deciding factor is usually the platform you are already committed to, not a raw benchmark.

Pricing and the economics of density

The isolate model is not just faster, it is cheaper, and the reason is density. A container-based function reserves memory for its whole invocation and is billed on GB-seconds of that reservation; keeping many warm to avoid cold starts costs money even while idle. Isolates pack thousands onto a host and spin up per request essentially for free, so edge compute is typically billed on a lighter basis (units of CPU time and/or invocations) and comes out materially cheaper for the thin, high-volume workloads it targets.

That economic shape reinforces the architectural advice. Edge Functions are cheap because they are small and short; the pricing rewards exactly the workloads that fit the model — run on every request, finish fast — and punishes the ones that do not, because a handler that needs more CPU or memory than the edge budget is either impossible there or forced into awkward workarounds. Let the cost model and the technical model agree: put the thin, global, latency-sensitive layer at the edge, and keep the heavy, stateful, region-bound work in regional functions where it belongs.

A decision framework

Strip away the hype and the choice to run a given piece of code at the edge comes down to a few honest questions:

A row that pushes you the other way is a signal to keep that route on a regional Node function — and that is a perfectly good answer, not a defeat. The strongest architectures use both deliberately: a thin edge layer that personalizes, routes, authenticates, and streams close to the user, in front of regional functions that do the heavy, stateful work. The edge is a scalpel, not a hammer; used on the right cut, it is the cleanest latency win Vercel offers.