Five years ago, “edge computing” was mostly a marketing term attached to CDNs and IoT whitepapers. Today it’s a concrete infrastructure option with real products, real pricing, and real tradeoffs. Cloudflare Workers, Vercel Edge Functions, AWS Lambda@Edge, Fastly Compute - these exist, they’re in production at scale, and developers are making decisions about when to use them.

The question is not whether edge is real. The question is when running logic at the edge is the right architectural decision versus running it in a centralized cloud region.

What Edge Actually Means

The “edge” refers to compute nodes geographically distributed to be close to users. A CDN has always distributed static assets this way. Edge compute extends this to running code - not just serving files, but executing logic at the node closest to the request.

In practice:

• A CDN with edge functions has 100-300 nodes globally
• A traditional cloud deployment has one or a few regions
• An edge request might hit a node 20ms from the user instead of 100-200ms from a distant region

The latency difference is real, but it’s not the whole story. Edge compute comes with significant constraints that determine when it’s appropriate.

The Constraints

Cold start and runtime limits. Edge functions are designed for fast startup and short execution. Cloudflare Workers has a 50ms CPU time limit per request by default. Lambda@Edge is more generous but adds latency for cold starts. These aren’t suitable for long-running computations or heavy processing.

No persistent connections. You can’t hold a database connection open across requests at the edge the way you can in a traditional server process. Every request is stateless. This is a fundamental constraint, not a limitation to be worked around.

No filesystem. Edge functions have no access to local files. Everything must come from the code bundle, a KV store, or an external API call.

Limited local state. While options like Cloudflare KV, Durable Objects, and Workers AI exist, they’re not equivalent to a full database. They’re distributed data primitives with their own consistency characteristics.

Vendor fragmentation. The edge compute ecosystem is fragmented. Cloudflare Workers, Vercel Edge, and AWS Lambda@Edge have different runtimes, different APIs, and different capabilities. Code written for one doesn’t necessarily run on another.

Where Edge Compute Is Actually Useful

Request routing and A/B testing

Deciding which version of the application to serve, which region to redirect to, which feature flags are active for a given user - these decisions can happen at the edge before the request ever hits your origin. The computation is light, the latency savings are real.

// Cloudflare Worker: route traffic based on header
export default {
  async fetch(request) {
    const variant = getUserVariant(request);
    const origin = variant === 'a' 
      ? 'https://origin-a.example.com' 
      : 'https://origin-b.example.com';
    return fetch(new Request(origin + new URL(request.url).pathname, request));
  }
}

Authentication and authorization at the perimeter

Validating a JWT, checking a session cookie, enforcing geo-restrictions - these can happen at the edge before the request reaches your application. Requests that fail authentication never touch your origin.

This is a genuine architectural improvement: invalid requests get rejected closer to their source, your origin sees only pre-authenticated traffic, and the latency for valid users doesn’t change.

Personalization and localization

Serving localized content based on Accept-Language header, personalizing responses based on cached user preferences, adjusting content for different devices - these can be done at the edge without a round trip to the origin.

Static asset caching and transformation

Image optimization, format conversion, responsive image serving - these fit the edge compute model well. A CDN with compute can resize and optimize images at the edge based on the device requesting them.

Where Edge Compute Is Not the Right Answer

Anything requiring a relational database

If your request requires a SQL query against a normalized database, you need a connection to that database. Your database is not at the edge. You’re still making a round trip to wherever the database is. In many cases, this eliminates the latency benefit of edge compute - you saved 80ms on the network but still wait 50ms for the database query. The total isn’t dramatically better and you’ve added complexity.

Complex business logic

The 50ms CPU limit on Cloudflare Workers is not a lot. Parsing large payloads, running algorithms with significant computation, doing anything with non-trivial fan-out - these don’t fit. The edge is optimized for fast, lightweight work.

Applications that need global consistency

Distributed state is hard. Edge compute makes it easier to read distributed state fast; it doesn’t make it easier to write consistently. If your application needs strong consistency across regions - financial transactions, inventory management, anything where concurrent writes matter - edge compute doesn’t help and can complicate the consistency model.

Greenfield applications where simplicity matters

A standard cloud deployment with a server in one or two regions, a connection to a database, and a CDN in front for static assets is simple to understand, simple to debug, and handles most traffic patterns correctly. The operational overhead of edge compute - distributed debugging, regional consistency issues, vendor-specific APIs - is real. Don’t add it unless you have a specific problem it solves.

Three Concrete Scenarios

Scenario 1: SaaS app with a global user base and a database in us-east-1

The app is primarily used in North America, but has growing users in Europe and Asia-Pacific. European users are experiencing 300-400ms API response times.

Edge compute won’t solve this if the bottleneck is the database query - the round trip to Virginia happens regardless of where the Worker runs. The right moves: add a read replica in EU-West, or add aggressive caching at the edge for responses that can tolerate slight staleness. Move JWT verification and rate limiting to the edge (saves 1 round trip). Keep all database-touching logic in the origin.

Scenario 2: E-commerce site with A/B testing and personalization

The product team runs 15 concurrent A/B tests. Feature flags are checked on every page load. User preferences (country, language, previously viewed categories) affect which content is served.

This is a strong fit for edge compute. Feature flag evaluation based on a cookie or a hashed user ID is fast, stateless, and runs well at the edge. Personalization based on a small user preference cache (stored in Cloudflare KV or equivalent) also works. The edge node makes the routing decision; the origin serves the actual content. Result: the routing overhead disappears from latency, and A/B traffic is split before it ever reaches the origin.

Scenario 3: Startup building their first product

Single region, small team, PostgreSQL on RDS, Next.js on Vercel. Someone suggests “we should move our auth middleware to the edge.”

Don’t. The complexity cost is not worth it at this stage. Vercel already puts your server functions close to users within each supported region. The operational overhead of debugging edge-specific behavior, handling vendor lock-in to Cloudflare Workers vs Vercel Edge, and dealing with the constraints (no persistent connections, CPU limits) is real. The latency gains at small scale are marginal. Build the product first.

Decision Matrix

Workload	Edge	Cloud Region
JWT / session validation	Yes	Fine too
A/B testing / feature flags	Yes	Yes
Rate limiting	Yes	Yes
Database queries	No	Yes
Complex business logic	No	Yes
File processing	No	Yes
Auth with social login (OAuth round trip)	No	Yes
Geo-blocking / redirects	Yes	Overkill
Image transformation	Yes	Possible
Real-time personalization from KV store	Yes	Fine

The edge is a real option that was not available five years ago. It is not a replacement for centralized compute. It is a fast, constrained environment for lightweight decisions that sit between the user and your origin. The teams that use it well apply it to exactly that layer - and keep everything else where it is easier to reason about and debug.