Edge vs serverless: when to use each

Every vendor now sells both "edge" and "serverless", and the marketing materials make them look interchangeable: same functions, same triggers, just one is closer. They are not interchangeable. They are different execution models with different budgets, and choosing wrong shows up as either slow requests or a colossal bill.

This is the decision procedure we use internally when someone asks where a new workload should run. It is deliberately short because the interesting part is the boundary, not the definitions.

What each one actually is

Serverless, in the region-based sense, is a function that runs in a data centre near your data. It has a real CPU budget, a generous memory envelope, a timeout measured in minutes rather than milliseconds, and it can hold state through long-running work, filesystem access, and database connections. Its price is boot time and cold starts, plus a latency floor of one network round-trip from the user to your region.

Edge is compute that runs in the network path — typically in a lightweight isolate on a CDN node, closer to the user than any region is. It starts fast, executes fast, and dies fast. The price is that its limits are aggressive: small memory, short execution time, no meaningful state, limited libraries, and no guarantee that two requests from the same user hit the same node.

The feature matrices list the same checkbox next to both: "run code on request". The execution models could not be more different, and every decision mistake we have seen is someone trusting the matrix.

Start with the data, not the latency map

People start these conversations with latency maps: "the user is in Lagos, our region is Frankfurt, edge must be faster." That reasoning only holds when the request can be answered from the edge node.

The first question is never "how far is the user from a node." It is "where is the data this request needs, and can it live at the edge?" If the answer is a database in one region, edge compute still has to cross the network to reach it, and you have added a hop without moving the data. The user is no closer to their data; you have just relocated the compute and kept the worst part.

So the decision starts with the data plane. Read-heavy, cacheable, or user-request-local data can live at the edge. Anything that needs a database, a long transaction, or a connection to another service has to terminate near that service, no matter where the user is.

When edge is the right call

Edge earns its keep on the request-shaping layer, the work that has to happen on every request and has to happen fast:

• Authentication and authorisation checks that can be answered from a signed token and a small allow-list.
• Request rewriting, redirects, geo-based routing, A/B assignment, and feature-flag evaluation.
• Caching with per-request personalisation — the cache decision and the personalisation both live in the request path.
• Bot and abuse filtering, rate limiting, and validation that rejects bad requests before they touch a region.
• Small computations repeated everywhere: signing, hashing, image resizing, format negotiation.

The common thread is statelessness. Edge is for work that is a pure function of the request plus a tiny bit of config, and that can answer without a round-trip to a region. If you can describe the work as a rewrite of the request before the origin, it belongs at the edge.

When serverless is the right call

Everything that touches shared state, or that takes longer than an edge function is allowed to live, belongs in a region:

• Anything that reads or writes a database, because the compute has to be beside the data.
• Webhooks and integrations that call external services and need retries, backoff, and idempotency.
• Long-running work — batch jobs, exports, media processing — where minutes of execution are a feature, not a limit.
• Workloads that need libraries and native modules the edge sandbox cannot host.
• Anything with compliance or data-residency constraints that pin data to a specific region.

The pattern is the inverse of edge. If the work needs to coordinate with anything outside the current request, or if it cannot afford to be killed mid-flight, it is not edge work. This is also where the cost model of serverless pays off: you get the warm-pool reliability without paying for idle compute.

The hybrid that actually works

Most of our production traffic uses both, in a division that has stayed stable for two years. The edge function handles everything it can answer locally — auth, routing, cache, abuse — and forwards only the requests that genuinely need business logic to a region-based function. The region function sees fewer, more meaningful requests, which lowers its load, its concurrency cost, and its cold-start exposure.

The boundary is explicit, not accidental. Edge does not try to be a database client. Region functions do not try to handle request shaping. Every team knows which side a given piece of work lives on, because the split follows one rule: work that is a function of the request lives at the edge; work that is a function of the system lives in a region.

A decision procedure

When someone asks where to run something, we ask four questions in order. If the answer to the first two is no, it is region work and the conversation is over.

1. 01 Can this be answered without touching shared state?
2. 02 Can it complete within the edge sandbox limits?
3. 03 Would moving it closer to the user actually reduce the time the user waits?
4. 04 Is the extra operational complexity of a second compute tier worth the latency you save?

The fourth question is the one most teams never ask. Edge adds a second place for logic to live, a second deployment target, a second set of logs. If the latency you save is 30 ms on a request your users mostly do not feel, you have bought complexity for nothing. We have rejected more edge candidates on question four than on all the technical questions combined.

Edge and serverless are not competitors. They are two rungs of the same path — request shaping at the edge, business logic in the region — and the best architectures know which rung each piece of work belongs on. Start with the data, be honest about complexity, and the boundary draws itself.