Edge computing — running code at locations closer to users than your main data center — used to mean buying hardware in colocation facilities. The cloud providers now expose this as a service. Cloudflare Workers, AWS Lambda@Edge, Vercel Edge Functions — different products solving overlapping problems with different tradeoffs.
This post is what each one actually does, when they pay off, and the cases where running things at the edge sounds great but is the wrong call.
What "Edge" Means in 2026
Edge computing has multiple definitions. For this post:
Edge = code that runs at a CDN's points of presence (PoPs) rather than in centralized cloud regions. A user in Tokyo hitting your service runs code in Tokyo, not in us-east-1.
This is distinct from:
- Mobile edge (code on user devices) — different problem space
- Industrial edge (code in factories) — different problem space
- Regional cloud (one region per continent) — this is just multi-region, not edge
The pitch: lower latency for users far from your primary region, lower bandwidth costs by serving closer to origin, faster response for cacheable content.
The Major Platforms
Cloudflare Workers. V8 isolate-based. Fast cold starts (microseconds). 50ms CPU time per request on the free tier. KV, R2, Durable Objects for state. JavaScript/TypeScript, Rust via WASM.
AWS Lambda@Edge. Lambda functions attached to CloudFront. Slower cold starts (100ms-1s). Limited runtime (no async work outside the request). Tighter AWS integration.
Vercel Edge Functions. V8 isolates similar to Cloudflare Workers. Tighter Vercel integration. Good for Next.js deployments.
Netlify Edge Functions. Deno-based. Similar runtime model to Vercel.
Fastly Compute@Edge. WebAssembly-based. Strong on performance, smaller ecosystem.
Deno Deploy. Standalone Deno-based edge runtime.
For most use cases, the choice is between Cloudflare Workers (if you are Cloudflare-centric) and Vercel Edge Functions (if you are deploying a Next.js app).
What Each One Is Good For
The strengths break down by use case:
Cloudflare Workers:
- Global low-latency request handling
- A/B testing logic and feature flags at the edge
- Personalization without round-tripping to origin
- API gateways and request transformation
- Strong free tier; scales economically
Lambda@Edge:
- AWS-integrated use cases (CloudFront customization)
- When you need access to Lambda's broader runtime
- Existing AWS investment
Vercel/Netlify Edge:
- Next.js or Svelte apps with edge routes
- Authentication checks before hitting the origin
- Geolocation-aware responses
Compute@Edge (Fastly):
- Heavy customization of CDN responses
- WASM-based portability requirements
Cold Starts and Execution Models
The most consequential technical difference.
V8 isolates (Cloudflare, Vercel, Netlify): Each function shares a V8 process with thousands of others. Cold start is microseconds because the runtime is already warm. No container startup.
Lambda@Edge: Each function runs in its own Lambda container. Cold start is 100ms-1s. Hot starts are fast (millisecond range).
WebAssembly (Fastly): Cold start is sub-millisecond. Strong sandboxing.
For a function that runs once per request and exits, V8 isolates dominate. For a function with a longer warm period and more substantial code, Lambda@Edge is competitive once warm.
Limits
Each platform has limits to know about:
Cloudflare Workers:
- 10ms CPU time on free tier; 50ms on paid (or unlimited with separate billing)
- 128MB memory
- No persistent local storage (use KV, R2, Durable Objects)
- No traditional Node.js APIs (use Web standards)
Lambda@Edge:
- 5s execution for viewer requests/responses, 30s for origin
- 128MB memory for viewer; 10GB for origin
- Most Lambda restrictions apply
Vercel Edge Functions:
- 30s default timeout
- 4MB request/response size
- Streaming responses supported
These limits matter. Long-running work, large responses, or heavy computation might not fit at the edge.
What Edge Is Actually Good For
The patterns where edge consistently wins:
Authentication. A JWT check at the edge before forwarding to the origin. Invalid requests die at the edge; origin only sees authenticated traffic.
// Cloudflare Worker
export default {
async fetch(request: Request): Promise<Response> {
const token = request.headers.get("Authorization")?.replace("Bearer ", "");
if (!token || !await verifyJWT(token)) {
return new Response("Unauthorized", { status: 401 });
}
return fetch(request); // forward to origin
},
};
A/B testing. Decide which variant a user sees at the edge. Set a cookie; route the user consistently across visits.
Personalization. Inject user-specific content into a cached page. The page is cached; the personalization is per-request.
Geolocation routing. Send users to the right region based on their location. EU users to EU origin, US users to US origin.
Request transformation. Rewrite URLs, add headers, modify responses before they reach the user.
API rate limiting. Bounded counters per-IP or per-user at the edge.
What Edge Is Not Good For
The cases where the edge model breaks down:
Heavy computation. Edge runtimes have CPU limits and short execution times. Image processing, ML inference, complex business logic — usually wrong for edge.
Database-heavy work. Each edge location is far from your primary database. A request that hits the database 10 times has 10x the latency of doing the database work in the origin region.
Stateful application logic. Most application state still lives in databases in central regions. Edge code that needs state pays latency to fetch it.
Most CRUD APIs. A REST API where every request reads/writes a database does not benefit from being at the edge.
The general rule: edge is good for request transformation, decision-making, and cacheable content. Edge is bad for real application logic that needs central state.
Edge Data Stores
The platforms have started offering edge-local data:
- Cloudflare KV: eventually consistent key-value, 60s+ to propagate.
- Cloudflare R2: S3-compatible object storage, edge-replicated.
- Cloudflare Durable Objects: strongly-consistent objects pinned to one location.
- Vercel KV: Redis-based.
- Fastly Config Store: small static config.
These help with simple state at the edge but are not full databases. Use them for feature flag values, A/B test assignments, session data — not for the main application data.
Cost Comparison
Rough numbers for moderate workloads:
- Cloudflare Workers: $5/month for 10M requests, then $0.50/M.
- Lambda@Edge: $0.60 per million requests + Lambda compute pricing.
- Vercel Edge: included in the Vercel plan; tiered pricing.
- Fastly: $0.50 per million requests.
For request-volume-heavy workloads, Cloudflare's pricing tends to be the cheapest. For low-volume custom logic, Lambda@Edge's pay-per-use model can be competitive.
When to Avoid Edge
Even when edge sounds appealing, several patterns are red flags:
- "We want to put our API at the edge for performance." Usually wrong. Origin-region APIs are usually faster end-to-end because they are closer to the database.
- "We need to run business logic at the edge." Most business logic is not edge-friendly.
- "Edge will solve our latency problem." Maybe, but database calls from the edge usually dominate the latency budget.
The right framing: edge is for the work that genuinely benefits from being near the user. Authentication, personalization, A/B testing, geo-routing. Not "everything I used to run in Lambda, but at the edge."
A Practical Recommendation
For most teams in 2026:
- Authentication and rate limiting at the edge for public APIs.
- A/B testing and feature flag evaluation at the edge for the parts of the app that benefit.
- Personalization injection at the edge for cached marketing/content pages.
- Everything else in the origin region where the database lives.
This pattern captures most of the edge value without paying the edge tax everywhere.
For Next.js / Vercel apps: Vercel Edge Functions are well-integrated. For everything else: Cloudflare Workers tends to win on price and simplicity.
Evaluating edge computing for an application and not sure which parts genuinely benefit? We help teams identify the right workloads for the edge and avoid the ones that pay edge costs without edge benefits. scopeforged.com