Edge Functions Explained: What Runs Where

Most edge platforms do not start a container per function. They run your code in a V8 isolate, the same sandboxing mechanism a browser uses to keep tabs apart.

Cloudflare's documentation describes the model in detail. A single instance of the runtime can run hundreds or thousands of isolates, seamlessly switching between them. Each isolate has its own memory, and creating one inside an already running process avoids most of the cold start cost of booting a virtual machine. The same page says an isolate can start around a hundred times faster than a Node process in a container or virtual machine.

Jade Fisher reached a similar picture after reading the source of Vercel's open edge runtime: each execution gets a lightweight execution context within the same V8 engine, not a separate process or container. Fisher's article estimates isolates at kilobytes each against megabytes for containers, which is why a provider can afford to keep code warm in so many locations.

The practical consequences for developers are these.

• Cold starts are small. You can put an edge function in front of every request without the latency spikes that regional functions sometimes show after idle periods.
• Global state does not persist reliably. Cloudflare warns that isolates may be evicted for resource limits or other reasons, so it advises against storing mutable state in your global scope unless you have accounted for that.
• Requests in different locations run in different isolates. A counter in memory in Frankfurt knows nothing about one in Sydney. Shared state must live in a store.

Isolates are fast because they leave things out. A guide on the DEV Community lists the trade-off plainly: edge runtimes offer Web Platform APIs only (Fetch, Streams, Crypto, URL, etc.), strict code size limits, and short execution timeouts, compared with full Node.js core modules, native addons and longer timeouts in a regional Node runtime.

The same guide catalogs the failures developers hit when moving code to the edge.

1. Missing core modules. Imports of fs, net or Node's crypto fail because there is no filesystem, no raw TCP socket and a different crypto API. The fix is the Web Crypto API (crypto.subtle) and fetch.
2. Dynamic code evaluation. Libraries that call eval or new Function at runtime are blocked.
3. Native modules. Packages with C++ or Rust bindings, such as image processing libraries, cannot load.
4. Database drivers. Drivers that open a TCP connection to Postgres or MySQL do not work without an HTTP or WebSocket based alternative.

Check each dependency before you choose the edge for a route. A single transitive dependency that touches fs can make the whole bundle fail to deploy, often with an error message that names the wrong package.

Latency is the reason to run code at the edge, and the database is the reason it often fails to deliver. If your database lives in one region, every query from an edge location has to cross the distance you were trying to avoid.

A public discussion on the Supabase GitHub shows what this looks like in practice. One developer reported that a hello-world function answered in about 100 ms from anywhere, but a function that made a few database calls went from 250ms in us-west to 1.1s in us-east to 2.3s in se-asia, and concluded that having the database and the function in different regions defeated the point.

The arithmetic is simple. Suppose a user in Singapore requests a page whose handler makes four sequential database queries, and the database is in Virginia.

The second setup is faster even though the function is further from the user, because the long trip happens once instead of five times. This is why the Stack Overflow blog's reporting on edge infrastructure notes that for DB-heavy workloads you should use the routing and caching features of the network rather than querying a distant database from every edge location.

There are three ways out.

• Run the data-heavy function in the database's region. Many platforms let you pin a function to a region for exactly this reason.
• Cache at the edge. Serve cached results and revalidate them in the background.
• Move read data closer. Use read replicas or a globally replicated key-value store for data that changes rarely.

The engineers interviewed by the Stack Overflow blog describe the right workloads. Functions that benefit are I/O-bound, not CPU-bound, and Akamai's Chris Daley sums it up as not general purpose compute so much as shaping traffic.

Netlify's list of common uses matches that description.

• Conditional routing based on cookies, headers or location.
• Adding or changing response headers, including security headers.
• A/B testing by splitting traffic between routes.
• Setting cookies for sessions or experiments.
• Personalizing by location, such as currency, language or legal notices.
• Authentication checks that reject unauthenticated requests before they reach the origin.

Each of these can be decided from the request itself, or from a signed token or small cached value, with no database query. That is the pattern to look for. If the decision needs fresh data from your primary database, it probably belongs in the region where that database lives.

Work that does not belong at the edge includes long-running jobs, image and video processing, PDF generation, heavy computation, anything that needs a native library, and anything that holds a persistent database connection.

Walk through these questions for each route or function.

1. Can it decide using only the request, a token or a cached value? If yes, the edge is a good fit.
2. Does it make more than one query to a single-region database? If yes, run it in that region.
3. Does it need Node core modules, native packages or a TCP database driver? If yes, use a regional runtime.
4. Can it finish in a few seconds with modest CPU? If no, use a regional function or a background job on an origin server.
5. Is the response cacheable? If yes, cache it at the edge and render it wherever the data lives.

Many applications end up with a thin edge layer for authentication and routing in front of a regional backend that does the real work. That split keeps the latency benefit without fighting the distance to the data.

Edge code is still production code, and a few habits keep it reliable.

• Test in the real runtime. The DEV Community guide's main warning is that code which works in development under Node can fail under the edge runtime. Use the provider's local emulator, and run integration tests against a preview deployment.
• Keep the bundle small. Edge platforms enforce code size limits, and every dependency adds cold start time and risk.
• Log with request IDs. A request may pass through an edge function and then a regional function. Pass one ID through both so you can trace it.
• Set timeouts on outgoing fetches. An edge function waiting on a slow upstream ties up its execution budget and the user's patience.
• Never trust location headers for security. Use them for personalization, not for access control.

If you use AI coding agents to write functions for a particular runtime, give them the runtime's limits up front. Quanta Intelligence skills can package those constraints so an agent does not reach for fs in code that will run in an isolate.