Edge functions are small units of server-side code that run inside a lightweight sandbox — a V8 isolate or a WebAssembly instance — deployed simultaneously across a provider's global network of points of presence, instead of one or two regions. The pitch is latency: a request hits the location physically closest to the user, runs in a sandbox that starts in sub-millisecond time, and returns a response without the cold-start penalty containers carry. The tradeoff is a much smaller surface area than a full server runtime: strict CPU and memory caps, no persistent filesystem, and no guarantee of a long-lived connection to anything.
What changed in 2026
- Node.js compatibility widened. Cloudflare Workers'
nodejs_compat flag and Vercel's Edge Runtime now cover enough of the Node API surface — streams, crypto, buffer — that many existing libraries run unmodified, which was not true a couple of years ago.
- WinterTC standardization matured. The effort to align Deno, Cloudflare, Vercel, and Node around common web-platform APIs (
fetch, Request, Response, ReadableStream) reduced the "works on one edge runtime, breaks on another" problem.
- Wasm inside edge functions became common for CPU-heavy work — image transforms, parsing, compression — because a Wasm module executes more predictably inside an isolate than interpreted JavaScript for tight compute loops.
- Edge-native databases went mainstream. Neon, PlanetScale, Turso, Cloudflare D1, and Upstash all ship HTTP or WebSocket-based drivers built specifically for runtimes that cannot hold a raw TCP connection open.
- Frameworks default to edge where it fits. Next.js, SvelteKit, and Remix all let you opt individual routes into an edge runtime, treating it as a deployment target choice rather than a separate app.
The core constraints
| Constraint |
Typical limit |
Why it exists |
| CPU time per request |
Low tens of milliseconds (varies by provider/plan) |
Isolates share a process; long CPU bursts would starve neighbors |
| Memory |
Roughly 128MB |
Keeps thousands of isolates resident per machine |
| Filesystem |
None persistent |
Isolates are ephemeral and stateless by design |
| Outbound TCP |
Often restricted to HTTP/WebSocket, not raw sockets |
Isolate sandboxes do not expose a full socket API |
| Dependencies |
No native/binary addons |
Native code cannot run inside a V8 isolate or Wasm sandbox |
| Execution model |
V8 isolate or Wasm instance |
Enables sub-millisecond cold starts vs container-based serverless |
These constraints are deliberate, not incidental: they are what make it possible to run a function in fifty-plus locations simultaneously and start it in microseconds. A Wasm module that starts that fast cannot also carry the weight of a full OS process.
What edge functions are actually good for
Edge functions fit request-scoped logic that needs to run close to the user and finishes fast: authentication checks and redirects, A/B test bucketing, geolocation-based routing, header rewriting, lightweight personalization, bot detection, and image or asset transformation. They are a poor fit for anything requiring sustained CPU (video encoding, large batch jobs), a persistent database connection pool, or dependencies with native bindings.
Common mistakes
Assuming a database call at the edge is "close" by default. The function is close to the user; your database is not, unless you are also using an edge-replicated or HTTP-native database. A round trip to a single-region Postgres instance from fifty edge locations can be slower than just running the function in that one region.
Porting a Node backend wholesale. Auth libraries, ORMs, and frameworks with native dependencies or long-lived connections often fail silently or throw unclear errors under an edge runtime — check compatibility before migrating a route.
Treating CPU limits as generous. Heavy JSON parsing, regex-heavy logic, or synchronous cryptography can blow through a CPU budget that was never meant for that kind of work — that is where compiling the hot path to Wasm often pays off.
Ignoring cold-region cache misses. Even isolate-based runtimes reload code and reconnect to dependencies on the first request to a given location; expect a small first-hit penalty per point of presence, not a single global first-hit penalty.
FAQ
Are edge functions the same as serverless functions?
They are a subset of serverless, distinguished by running in many locations on lightweight sandboxes with tighter limits, versus a regional serverless function running in a container in one or a few regions.
Can edge functions replace my whole backend?
Rarely entirely. Most architectures use edge functions for latency-sensitive, request-scoped logic and keep heavier processing, background jobs, and stateful services on regional serverless or traditional servers.
Why can't edge functions hold a normal database connection?
The isolate or Wasm sandbox model that gives fast cold starts does not expose raw TCP sockets in most providers, so drivers use HTTP or WebSocket transport instead, which behaves differently under connection pooling.
Do edge functions support WebAssembly?
Yes, and increasingly by design — Fastly Compute runs on WASI-based Wasm natively, and other providers support compiling hot paths to Wasm for predictable, fast execution inside the same isolate model.
Where to go next