The marketing pages from every cloud platform promise you the same thing: "functions that scale to zero and run anywhere in the world in milliseconds." The actual answer to whether you want an edge function or a serverless function depends on constraints the marketing copy won't tell you about: cold start time, supported runtimes, available memory, data locality, and what your code actually does on a typical invocation.
I've shipped production code on both architectures across a few companies. The wrong choice shows up as either a cost spike three months in or an outage the first time traffic doubles. Picking the right one upfront isn't hard once you know the actual mechanics.
What people mean when they say "edge"
Edge functions are code that runs at the point of presence closest to the user. Cloudflare Workers, Vercel Edge Functions, Netlify Edge Functions, Deno Deploy, and Fastly Compute all fit this shape. They're deployed to hundreds of small data centers worldwide, and a request gets routed to the nearest one based on the user's DNS or anycast route.
Serverless functions in the classical sense run in a small number of larger regions. AWS Lambda, Google Cloud Functions, and Azure Functions spin up containers in specific data centers. They're geographically closer to your database than the user usually is, and they sit behind a routing layer that handles authentication and TLS termination before your code runs.
The two patterns are not the same. Edge compute runs everywhere but with tighter constraints. Serverless runs in a few specific places with fewer constraints per function. Treating them as interchangeable is the most expensive mistake teams make.
What actually changes between them
The differences that matter for real code:
Runtime. Edge functions usually run on JavaScript/WebAssembly runtimes (V8 isolates, Lucet, or similar) and have smaller standard libraries. You can't just import a Node module that depends on native bindings. Serverless functions run on full language runtimes and have access to native dependencies, system libraries, and bigger standard libraries.
Cold start. Edge functions cold start in single-digit milliseconds because they're already running on lightweight isolates that warm up fast. Serverless functions cold start anywhere from 200ms to several seconds depending on language, memory, and image size. Init code, DB pools, and library imports all contribute to this.
Memory and CPU. Edge functions typically have lower per-invocation memory caps (128MB to 512MB common) and limited CPU time. Serverless functions scale memory from 128MB up to 10GB+ and have generous time limits.
State. Edge functions are mostly stateless. Durable storage has to live elsewhere (KV stores, eventual-consistency databases like DynamoDB Global Tables, or read-only replicas). Serverless functions have full access to whatever cloud-native storage lives in the same region.
Network locality. Edge functions can talk to your backend with extra latency because they're typically far from where your database runs. Serverless functions are usually colocated with the database, which is faster.
The shape of these constraints tells you where each architecture makes sense.
When edge functions win
Edge compute is the right answer when:
Your request needs a fast response and minimal logic. Authentication checks, A/B test routing, cookie writes, geo-based redirects, header rewriting, light API composition. Anything that returns a small JSON blob or sets a cookie in under 50ms total.
You're personalizing content from cache. Edge functions can hit a KV store at the edge and personalize a mostly-cached HTML response. This is the canonical Vercel/Netlify pattern: render the static page at the edge, then patch in personalized data from a KV look-up.
You're enforcing bot detection, rate limiting, or geo-blocking. The closer to the user this logic runs, the less garbage traffic hits your origin. Cloudflare's whole WAF and bot management product is built on Workers for this reason.
You need to keep latency low for users far from your origin. If your users are in Southeast Asia and your serverless functions run in us-east-1, every request eats 200ms of network latency. Edge compute collapses that.
The canonical examples are cookie checks, locale selection, dark-mode persistence, A/B test bucketing, and bot mitigation. Edge functions handle these in microseconds.
When serverless functions win
Serverless is the right answer when:
You need a full language runtime with native dependencies. Anything that uses TensorFlow, Puppeteer, sharp for image processing, or native Postgres drivers that depend on libpq.
You need to talk to a database with sub-10ms latency. Serverless functions in the same region as the database can hit it with local network latency. Edge functions pay full internet round-trip latency.
You're doing heavy compute per request. Long-running ML inference, complex document processing, multi-megabyte responses. Edge functions time out at 30 seconds or less on most platforms. Serverless functions can run for minutes or, with workflows, hours.
You have integration-heavy code that depends on cloud SDKs. AWS SDK calls from an edge function work differently than from a Lambda function. Anywhere you have a deep cloud dependency, serverless functions are simpler.
For backend API code, batch jobs, anything touching a real database, anything with cryptographic operations that need constant-time libraries, serverless is still the safer default.
The hybrid pattern that actually works in production
Most non-trivial production systems end up using both. A typical setup:
- Edge function at the front, handling auth, geo-routing, and personalization
- Serverless function behind it, talking to the database and doing the real work
- Static assets served from CDN, cached at the edge
The edge function is usually a thin shell. It validates the JWT, checks the rate limit, looks up user preferences in an edge KV, and forwards the request to a serverless function. The serverless function does the actual business logic with full library and database access. The user never knows the difference, but you get the latency benefits of edge for the common case and the flexibility of a serverless function for everything else.
If you're building a Next.js app, most of this maps cleanly to the framework's middleware API plus API routes. The framework handles the routing and you decide which code lives in middleware versus in API routes. For a deeper walkthrough of the framework itself, start with Next.js production deployment patterns and the routing primitives that map to edge vs serverless.
Real-world cost differences
People underestimate the cost dimension because edge functions look almost free at small scale. The reality at production traffic:
Cloudflare Workers: free tier covers 100k requests per day. After that, $0.30 per million requests plus CPU time. For high-volume low-logic traffic, this is the cheapest option in cloud.
Vercel Edge Functions: bundled into the platform's edge requests quota. Pricing is per request and per CPU time, and the matrix gets complex fast.
AWS Lambda: $0.20 per million requests plus GB-seconds of compute. Cold starts cost money because the platform charges for init time.
The trap with edge functions is that the cost per request is low, but the total requests scale with your user geography. A product with users in 50 countries pays for 50 edge regions serving traffic. A serverless function in three regions serving the same traffic might actually be cheaper. Run the numbers for your specific traffic shape.
Cold start isn't the whole story
A common misconception is that edge functions always beat serverless functions on latency. That's only true for cold starts. For warm functions, a serverless function in the right region is often faster than an edge function going across the world.
The pattern is:
- Cold edge function: 5-10ms
- Warm edge function: 1-5ms
- Cold serverless function: 200ms to 2s
- Warm serverless function: 5-20ms
If your traffic is bursty, edge wins. If you have sustained traffic that keeps functions warm, serverless catches up. The right answer depends on what your traffic actually looks like, not what the marketing pitch says.
How to pick without burning six months
A short heuristic:
- If the function does anything beyond routing, header writing, or KV look-up, default to serverless.
- If you have users in places you can't easily serve from a single region, layer edge in front.
- If you have authentication or rate limiting that should happen before any backend logic, put it at the edge.
- If you're doing image processing, ML inference, document parsing, or anything with native deps, serverless.
- If your traffic is super bursty and the cold start shows up in error metrics, edge.
When in doubt, prototype both. The cost of choosing wrong is usually small. The cost of not switching once you realize which one fits is usually a few months of unnecessary latency or unnecessary spend.
For most teams starting from scratch in 2026, the recommended path is edge for the front door, serverless for everything that touches state. That single split covers the bulk of real applications and lets you ship your frontend fast without locking yourself into a specific backend choice.
