Cloudflare, Fastly, AWS Lambda@Edge, and a dozen other vendors are selling the same dream: your code running 50ms from every user on the planet. Real-time, globally distributed, infinitely scalable, zero cold starts. The pitch is compelling. The reality is more complicated.

What Edge Compute Actually Means

“Edge” in “edge computing” refers to points of presence closer to users than a central data center. A CDN has edge nodes in 100+ cities. Running code at those nodes means the computation is geographically close to the user.

The implied promise: low latency everywhere. The actual benefit: reduced network round-trip time. The distinction matters because network latency is not the only latency.

A request to a Cloudflare Worker:

  1. User to nearest Cloudflare PoP: 10-30ms
  2. Worker execution: 1-50ms
  3. Worker to origin database: 30-80ms (back to your central region)
  4. Origin response to Worker: 30-80ms
  5. Worker response to user: 10-30ms

Total: 81-270ms. The user saved 60ms on the outbound trip. They lost 60ms when the Worker had to call back to your origin database in a single region.

The Database Problem

Edge compute is stateless compute. Your data lives in one place. Any request that needs to read or write data makes a round trip back to that place.

If your database is in us-east-1 and a user is in Mumbai, their request reaches a Mumbai Cloudflare PoP in 2ms. The Worker then calls your database in Virginia, which is a 160ms round trip. The user saved 10ms on the user-to-edge leg and paid 160ms for the edge-to-database leg.

The actual latency is dominated by database access, not user-to-edge distance.

When Edge Compute Actually Helps

Edge compute delivers on its promise for specific workloads:

Requests that do not need origin data:

  • A/B test cookie assignment
  • Geo-based routing and redirects
  • Request validation and rejection
  • Bot detection
  • Static content transformation (image resizing, header modification)
  • JWT validation

Requests where edge-native storage eliminates the origin call:

  • Cloudflare Workers KV (eventually consistent, globally distributed)
  • Cloudflare Durable Objects (single-region consistent, but moveable)
  • Fastly’s edge dictionary for configuration data

Caching at the edge:

  • This is just CDN. Edge compute makes sophisticated cache logic programmable.
  • Cache invalidation, vary headers, custom cache keys - all programmable.

The Marketing vs Reality Table

Promise Reality
“Sub-millisecond everywhere” True for cached/stateless requests only
“No cold starts” True for Workers/Fastly, false for Lambda@Edge
“Run closer to users” Yes, but database calls go back to origin
“Infinite scale” At per-request cost that grows linearly
“Global by default” Compute is global; data is not

Lambda@Edge Is Not the Same Thing

Lambda@Edge is different from Workers or Fastly Compute. It runs Lambda functions at CloudFront edge locations, but:

  • Cold starts are real (100ms+)
  • Maximum execution time is 5 seconds (viewer request/response) or 30 seconds (origin request/response)
  • Memory limits are lower than standard Lambda
  • You cannot use most AWS services from Lambda@Edge

Lambda@Edge is better understood as CDN logic programmability than as general-purpose edge compute. For origin request modification, custom headers, authentication at the CDN layer - it works. For general application logic, use a standard Lambda with a CloudFront distribution in front.

The Distributed Data Reality

The reason truly low-latency global applications are hard is not compute - it is data. Consistent, low-latency global data does not exist because of physics. Light travels at finite speed. The CAP theorem is not marketing.

Approaches that actually work:

Geo-distributed databases like CockroachDB, PlanetScale’s global option, and Fauna place data replicas globally. Reads from the nearest replica are fast. Writes coordinate globally and are slower. Works for read-heavy workloads.

Regional deployments with smart routing - deploy your full stack (compute + database) in 3-4 regions. Route users to the nearest region. Add CDN caching in front. This is what large companies actually do.

Data that does not need strong consistency - user preferences, feature flags, configuration - can be stored in eventually consistent edge storage (Workers KV) and accessed without origin calls.

What the Pricing Actually Looks Like

Cloudflare Workers: $0.30 per million requests + $0.02 per million GB-seconds of CPU. For most applications this is cheaper than Lambda. The math changes if Workers need to call a paid upstream API on every request.

The hidden cost: debugging and monitoring edge functions is harder than debugging centralized services. Local development approximates edge behavior but does not replicate it exactly. Distributed tracing across edge + origin + database adds tooling complexity.

The Right Use Cases

Build on edge compute when:

  • Your logic genuinely does not need per-request origin calls
  • You are doing CDN-layer logic (routing, auth, caching)
  • Cold start latency is unacceptable and you need the V8 isolate model
  • You are building a genuinely cacheable API with deterministic responses

Keep it centralized when:

  • Every request needs fresh database reads
  • You need complex business logic that is easier to debug centrally
  • Your operations team is small and cannot manage distributed debugging
  • The latency gain is under 50ms (users do not notice under 100ms differences)

Bottom Line

Edge compute is real, useful, and worth using for the right workloads. The marketing oversells the latency benefits for database-backed applications because it ignores the origin round trip. The actual gains are real for stateless compute, CDN logic, and edge-native storage patterns. Evaluate edge compute against your specific request patterns - if most requests need origin data, you will get less benefit than the vendors imply.