Server-First Architecture with Edge Runtimes: When to Move Computation from Client to Edge

The web development pendulum has swung from server-rendered PHP applications to thick JavaScript clients and back again. But the current shift to server-first architecture isn't a simple return to 2010. Edge computing platforms like Cloudflare Workers and Vercel Edge Functions have fundamentally changed what "server-side" means by placing execution within milliseconds of every user globally.

After migrating three production applications to edge runtimes over the past 18 months, I've learned that the decision isn't "edge vs serverless vs traditional backend" — it's understanding which layer handles which concern. This guide covers the architectural patterns that actually work, the migration gotchas that documentation doesn't mention, and the cost/performance trade-offs that determine whether edge computing makes financial sense for your application.

The Physics Problem Edge Computing Solves

A user in Singapore connecting to a US-East server experiences 200-250ms of network latency before receiving a single byte. This isn't a software problem you can optimize away — it's physics. Light travels through fiber optic cables at roughly 200,000 km/s, and Singapore to Virginia is about 15,000 km. Add routing overhead, TLS negotiation, and TCP handshakes, and you're looking at a quarter-second minimum.

Edge computing solves this by running code at 300+ global points of presence. Cloudflare's network means most users are within 10-50ms of an edge location. For a Next.js application I migrated last year, this translated to:

• Time to First Byte: 380ms → 62ms (84% reduction)
• Largest Contentful Paint: 2.1s → 0.9s (57% improvement)
• First Input Delay: 180ms → 45ms (75% reduction)

These aren't synthetic benchmarks. These are Real User Monitoring metrics from 50,000+ daily sessions across Southeast Asia, Europe, and South America.

Edge Runtime Architecture: V8 Isolates vs Containers

The performance characteristics of edge platforms stem from their runtime model. Traditional serverless (AWS Lambda, Google Cloud Functions) uses containers or microVMs. Each function invocation spins up an isolated environment with its own process space. Cold starts range from 100ms to several seconds depending on runtime and package size.

Cloudflare Workers and Vercel Edge Functions use V8 isolates — the same sandboxing mechanism Chrome uses for browser tabs. An isolate is a lightweight execution context within a shared V8 process. Starting a new isolate takes under 1ms because you're not booting an operating system or initializing a runtime. You're creating a new JavaScript context.

The trade-off: V8 isolates don't support the full Node.js API. No fs, no child_process, no native modules. You get the Web Platform APIs: fetch, Request, Response, crypto, TextEncoder. This constraint is actually a feature — it forces you to write portable code that could run anywhere.

Migration Pattern: Identifying Edge-Ready Code

Not everything belongs at the edge. The first step in any migration is auditing your server-side code to identify what can move and what can't.

Start with your middleware and route handlers. For each function, check:

1. Node.js API usage: Does it use require(), fs, path, Buffer, or child_process? These won't work in edge runtimes.
2. npm package compatibility: Run your dependencies through the Cloudflare Workers or Vercel edge runtime locally. Many packages work fine; some don't.
3. Execution time: Profile each function. Edge runtimes typically limit CPU time to 25-50ms per request. Long-running operations need to stay in traditional serverless or containers.
4. Data access patterns: List all database queries and third-party API calls. High-latency operations negate edge benefits.

Complete Migration Example: Node.js to Edge Runtime

Here's a real example from a SaaS dashboard migration showing the full transformation pattern:

// Before: Traditional Next.js API route (Node.js runtime)
import { getServerSession } from 'next-auth'
import { prisma } from '@/lib/db'
import fs from 'fs' // Node.js API - won't work at edge
import path from 'path' // Node.js API - won't work at edge

export default async function handler(req, res) {
  const session = await getServerSession(req, res)
  if (!session) return res.status(401).json({ error: 'Unauthorized' })
  
  // Database query from single-region serverless
  const user = await prisma.user.findUnique({
    where: { email: session.user.email },
    include: { subscriptions: true }
  })
  
  // Reading feature flags from filesystem
  const flagsPath = path.join(process.cwd(), 'config', 'flags.json')
  const flags = JSON.parse(fs.readFileSync(flagsPath, 'utf-8'))
  
  return res.json({ 
    user,
    features: flags[user.tier] || flags.default
  })
}

This handler has multiple problems for edge deployment:

1. Prisma Client doesn't work in edge runtimes (it uses Node.js APIs internally)
2. Database queries from edge locations to a single-region Postgres instance add 100-200ms latency
3. fs and path modules are Node.js-specific and unavailable in V8 isolates
4. getServerSession relies on Node.js APIs for session storage

The solution isn't to force everything to the edge. It's to split concerns and transform imports:

// After: Edge middleware for auth, serverless for data
// middleware.ts (runs on Vercel Edge Runtime)
import { NextResponse } from 'next/server' // Edge-compatible
import { verifyJWT } from '@/lib/auth' // Must use Web Crypto API, not Node crypto

// Feature flags moved to edge-compatible KV store
import { kv } from '@vercel/kv' // Edge-compatible

export async function middleware(request) {
  const token = request.cookies.get('session-token')
  
  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url))
  }
  
  try {
    // JWT verification using Web Crypto API (edge-compatible)
    const payload = await verifyJWT(token.value)
    
    // Fetch feature flags from edge KV (not filesystem)
    const userTier = payload.tier || 'free'
    const flags = await kv.get(`feature-flags:${userTier}`) || await kv.get('feature-flags:default')
    
    const response = NextResponse.next()
    response.headers.set('x-user-id', payload.userId)
    response.headers.set('x-user-tier', userTier)
    response.headers.set('x-features', JSON.stringify(flags))
    return response
  } catch (err) {
    return NextResponse.redirect(new URL('/login', request.url))
  }
}

export const config = {
  matcher: '/api/user/:path*'
}

// app/api/user/route.ts (Node.js runtime for DB access)
import { prisma } from '@/lib/db' // Node.js runtime allows Prisma

export const runtime = 'nodejs' // Explicit Node.js runtime selection

export async function GET(request) {
  const userId = request.headers.get('x-user-id')
  const features = JSON.parse(request.headers.get('x-features') || '{}')
  
  // Database query runs in Node.js serverless, same region as DB
  const user = await prisma.user.findUnique({
    where: { id: userId },
    include: { subscriptions: true }
  })
  
  return Response.json({ 
    user,
    features // Passed from edge middleware
  })
}

Key transformation patterns:

1. Import changes: fs, path → @vercel/kv or Cloudflare KV
2. Crypto operations: require('crypto') → Web Crypto API (crypto.subtle)
3. Session management: NextAuth server sessions → JWT with edge-compatible verification
4. Database access: Moved to Node.js runtime route, not edge middleware
5. Configuration loading: Filesystem reads → KV store or environment variables

Node.js APIs that won't work at edge:

• fs, path, os - filesystem and OS operations
• child_process, cluster - process management
• net, dgram, tls - raw socket operations
• stream.Readable (Node-specific) - use Web Streams API instead
• Buffer (limited support) - use Uint8Array or ArrayBuffer
• require() - use ES modules (import/export) only
• process.cwd(), __dirname - no filesystem context

Complete code example showing problematic Node.js APIs:

// This code will FAIL at edge - demonstrates incompatible Node.js APIs
import fs from 'fs' // ❌ File system access
import path from 'path' // ❌ Path manipulation
import net from 'net' // ❌ Raw TCP sockets
import { spawn } from 'child_process' // ❌ Process spawning
import { Readable } from 'stream' // ❌ Node streams

export default async function handler(req, res) {
  // ❌ fs - reading files from disk
  const config = fs.readFileSync(path.join(__dirname, 'config.json'), 'utf-8')
  
  // ❌ child_process - spawning external processes
  const pythonProcess = spawn('python3', ['script.py'])
  
  // ❌ net - creating TCP connections
  const socket = new net.Socket()
  socket.connect(5432, 'database.internal')
  
  // ❌ Node.js streams
  const stream = new Readable({
    read() {
      this.push('data')
    }
  })
  
  return res.json({ result: 'This will never work at edge' })
}

// Edge-compatible alternative using Web APIs:
import { kv } from '@vercel/kv'

export const runtime = 'edge'

export default async function handler(req) {
  // ✅ Edge KV instead of fs
  const config = await kv.get('app-config')
  
  // ✅ Fetch API for HTTP-based data access
  const response = await fetch('https://api.example.com/data')
  
  // ✅ Web Streams API
  const readable = new ReadableStream({
    start(controller) {
      controller.enqueue('data')
      controller.close()
    }
  })
  
  return Response.json({ result: 'Edge-compatible code' })
}

Now authentication happens at the edge (JWT verification is pure crypto, no database), blocking unauthorized requests before they reach your origin. The database query runs in a Node.js serverless function in the same region as your database, minimizing latency.

Production Failure Case Study: Real Estate Platform Image Processing

The Company: PropertyHub (anonymized name)

PropertyHub, a real estate listing platform serving 2.5M monthly users across North America, attempted to migrate their image resizing service from AWS Lambda to Cloudflare Workers in Q3 2023. Their goal was to reduce image delivery latency for international users and cut costs.

Original Architecture:

• AWS Lambda (us-east-1) with Sharp library for image processing
• S3 bucket for original images (us-east-1)
• CloudFront CDN for distribution
• Average processing time: 120ms
• P95 latency for EU users: 450ms
• Monthly cost: $340 (Lambda + S3 + CloudFront)

Planned Edge Architecture:

• Cloudflare Workers for on-demand image resizing
• Workers fetch originals from S3, resize, cache at edge
• Expected P95 latency: <100ms globally
• Expected monthly cost: $180 (50% reduction)

What Actually Happened

Problem: Origin database queries for image metadata killed performance

Their image resizing workflow wasn't just transformation — it included authorization checks and watermark logic based on subscription tier:

1. Edge Worker receives request: /image/resize?id=abc123&width=800
2. Query PostgreSQL (us-east-1) for image ownership and user tier — 180ms from EU edge locations
3. Fetch original image from S3 — 220ms from EU edge locations
4. Apply transformations and watermarks based on tier
5. Return processed image

Measured Results After Deployment:

• EU users (London edge): 180ms (DB) + 220ms (S3) + 45ms (processing) = 445ms total
• APAC users (Singapore edge): 210ms (DB) + 240ms (S3) + 45ms (processing) = 495ms total
• US users: Latency actually increased from 120ms to 380ms because the edge added network hops

Latency increased 200-300ms globally compared to their original Lambda architecture. The edge processing was fast (45ms), but the database and S3 queries from distant edge locations dominated total latency.

Additional Failures:

1. Database connection exhaustion: 50+ edge locations simultaneously querying a single PostgreSQL instance caused connection pool saturation during traffic spikes. They hit their RDS connection limit (500) within minutes of a product launch.

2. S3 request costs exploded: Every edge location independently fetched original images from S3. Previously, Lambda with EFS caching served repeated requests from cache. Edge deployment increased S3 GET requests by 15×, adding $280/month in S3 request costs.

3. Image processing CPU limits: Cloudflare Workers CPU time limits (50ms) were insufficient for large images (>5MB). 8% of requests for high-resolution property photos timed out.

Total Outcome:

• Latency increased 200-300ms globally (400% worse for some regions)
• Monthly cost increased to $640 (88% increase vs expected 50% reduction)
• Error rate increased from 0.1% to 3.2%
• Customer complaints about slow image loading increased 340%

Root Cause Analysis

The core mistake was moving compute to the edge while keeping data in a single region. Edge Workers are fast, but they can't overcome 200ms of cross-continent network latency for database queries and S3 fetches.

Specifically:

1. Single-region database: PostgreSQL in us-east-1 meant every edge location added 100-250ms for authorization checks
2. No edge caching strategy: Original images weren't cached at edge locations; every request fetched from us-east-1 S3
3. Synchronous dependencies: Image processing required real-time DB queries instead of embedding authorization data in signed URLs
4. Wrong workload for edge: Image processing is CPU-intensive and data-dependent — both poor fits for edge constraints

How They Recovered: Hybrid Pattern

PropertyHub rolled back the full edge migration and implemented a hybrid architecture:

New Architecture (Hybrid Edge + Regional):

1. Edge Layer (Cloudflare Workers):

   • Validates signed URLs with JWT (no database query needed)
   • Checks edge cache (R2 or Cache API) for processed images
   • If cache hit (85% of requests), returns immediately — 35ms average
   • If cache miss, proxies to regional Lambda

2. Regional Lambda (us-east-1, eu-west-1, ap-southeast-1):

   • Co-located with PostgreSQL read replicas
   • Database query: 2-5ms (same region)
   • S3 fetch: 15-30ms (same region)
   • Image processing: 45ms
   • Uploads result to Cloudflare R2 for edge caching
   • Total cold request: 95ms

3. Smart routing:

   • Edge Worker determines closest regional Lambda based on cf.country
   • Routes EU traffic to eu-west-1, APAC to ap-southeast-1, etc.

Results After Hybrid Implementation:

• Cache hit latency: 35ms globally (92% improvement)
• Cache miss latency: 95-120ms (73% improvement from original 450ms)
• Monthly cost: $285 (16% reduction from original $340)
• Error rate: 0.08% (below original baseline)
• Cache hit rate: 85% (edge caching working effectively)

Key Lessons Learned

What PropertyHub learned from this failure:

1. Co-locate compute with data sources: For workloads requiring database access or large file fetches, regional compute near data sources outperforms edge + remote data by 3-5×.

2. Edge is for cached content and stateless operations: Their successful pattern uses edge for the "hot path" (cached images, JWT validation) and regional compute for the "cold path" (database queries, S3 fetches, processing).

3. Embed authorization in signed URLs: By moving authorization data into time-limited signed URLs (JWT with user tier), they eliminated the database query dependency. The edge can validate the signature using Web Crypto API without network calls.

4. Use edge caching aggressively: Cloudflare R2 + Cache API reduced repeated processing by 85%. Without edge caching, edge compute provides minimal benefit.

5. Profile the complete request lifecycle: They initially profiled only the image processing code (45ms) and assumed edge would improve latency. They failed to profile database queries and S3 fetches, which dominated actual request time.

6. Consider total cost of ownership: The "cheap" edge solution became expensive when accounting for increased S3 requests, KV operations, and database connection scaling. Hybrid architecture reduced both latency and cost.

When PropertyHub now recommends edge:

• Image delivery from cache (85% of their traffic)
• URL signature validation (stateless crypto)
• Geo-based routing decisions
• Bot detection and rate limiting

When they use regional serverless:

• First-time image processing (cache miss)
• Database queries for authorization
• Large file operations (>5MB)
• CPU-intensive transformations

This failure taught them that edge-first doesn't mean edge-only. The winning architecture uses edge for what it does best (cached delivery, stateless logic) and regional compute for data-intensive operations.

Practical Edge Use Cases: What Actually Works

After working with edge runtimes in production, here are the patterns that consistently deliver value:

1. Authentication and Authorization

JWT verification, session validation, and role-based access control are perfect edge workloads. They're CPU-bound (crypto operations), stateless, and need to run on every request. Moving auth to the edge means unauthorized requests never hit your origin servers.

// Cloudflare Worker for API authentication
export default {
  async fetch(request, env) {
    const authHeader = request.headers.get('Authorization')
    if (!authHeader?.startsWith('Bearer ')) {
      return new Response('Unauthorized', { status: 401 })
    }
    
    const token = authHeader.slice(7)
    try {
      const payload = await verifyJWT(token, env.JWT_SECRET)
      
      // Add user context to request headers
      const modifiedRequest = new Request(request)
      modifiedRequest.headers.set('X-User-ID', payload.sub)
      modifiedRequest.headers.set('X-User-Role', payload.role)
      
      // Forward to origin with user context
      return fetch(modifiedRequest)
    } catch (err) {
      return new Response('Invalid token', { status: 401 })
    }
  }
}

2. A/B Test Routing and Feature Flags

Edge functions can route users to different application variants without a round trip to your backend. This is especially powerful for experimentation platforms.

// Vercel Edge Middleware for A/B testing
import { NextResponse } from 'next/server'

export function middleware(request) {
  const variant = request.cookies.get('experiment-checkout-v2')
  
  if (!variant) {
    // Assign user to variant (50/50 split)
    const newVariant = Math.random() < 0.5 ? 'control' : 'treatment'
    const response = NextResponse.next()
    response.cookies.set('experiment-checkout-v2', newVariant, {
      maxAge: 60 * 60 * 24 * 30 // 30 days
    })
    
    if (newVariant === 'treatment') {
      return NextResponse.rewrite(new URL('/checkout-v2', request.url))
    }
    return response
  }
  
  if (variant.value === 'treatment') {
    return NextResponse.rewrite(new URL('/checkout-v2', request.url))
  }
  
  return NextResponse.next()
}

3. Geolocation-Based Content

Edge runtimes provide request geolocation data without external API calls. This enables instant localization, currency conversion, or content personalization.

// Cloudflare Worker for geo-based pricing
export default {
  async fetch(request, env) {
    const country = request.cf.country // Cloudflare provides this
    
    const pricingTiers = {
      US: { currency: 'USD', price: 29 },
      GB: { currency: 'GBP', price: 25 },
      EU: { currency: 'EUR', price: 27 },
      IN: { currency: 'INR', price: 999 },
      default: { currency: 'USD', price: 29 }
    }
    
    const pricing = pricingTiers[country] || pricingTiers.default
    
    // Inject pricing into HTML response
    const response = await fetch(request)
    const html = await response.text()
    const modifiedHtml = html.replace(
      '{{PRICE}}',
      `${pricing.currency} ${pricing.price}`
    )
    
    return new Response(modifiedHtml, response)
  }
}

4. Image Optimization and Transformation

Cloudflare Images and similar services run at the edge, transforming images on-demand based on query parameters. This eliminates the need to pre-generate multiple sizes.

The Database Problem: Why Edge + Traditional DB = Slow

The biggest gotcha in edge computing is database latency. If your edge function in Tokyo needs to query a Postgres database in us-east-1, you've just added 200ms to every request. The edge runtime starts in 1ms, but then waits 200ms for the database. You've made things worse.

There are three solutions:

1. Edge-Native Databases

Cloudflare D1 (SQLite at the edge), Cloudflare KV, and Vercel KV replicate data globally. Reads happen from the nearest location. Writes propagate eventually (usually within seconds).

This works for read-heavy workloads where eventual consistency is acceptable:

// Cloudflare Worker with D1
export default {
  async fetch(request, env) {
    const url = new URL(request.url)
    const productId = url.pathname.split('/').pop()
    
    // Query runs against local SQLite replica
    const product = await env.DB.prepare(
      'SELECT * FROM products WHERE id = ?'
    ).bind(productId).first()
    
    return Response.json(product)
  }
}

2. HTTP-Based Database Clients

PlanetScale, Neon, and Supabase offer HTTP APIs that work in edge runtimes. They're slower than native Postgres drivers but compatible with edge constraints.

// Vercel Edge Function with Neon HTTP
import { neon } from '@neondatabase/serverless'

export const runtime = 'edge'

export async function GET(request) {
  const sql = neon(process.env.DATABASE_URL)
  const users = await sql`SELECT * FROM users LIMIT 10`
  return Response.json(users)
}

3. Hybrid Architecture (Recommended)

Use edge for stateless operations, serverless for database access:

• Edge middleware: Auth, routing, caching, header manipulation
• Serverless functions: Database queries, complex business logic
• Traditional backend: Long-running jobs, heavy computation

This is the pattern I use most often. Edge handles the hot path (90% of requests), serverless handles data access, and background workers handle async tasks.

Cost Analysis: Edge vs Serverless vs Containers

Pricing models differ significantly across platforms. Here's a detailed breakdown based on real-world usage patterns.

Assumptions for 1M monthly requests:

• Request payload: 2KB average (request + response)
• Compute time: 5ms average per request
• Traffic pattern: Steady throughout month (no major spikes)
• No database queries in this calculation (compute + bandwidth only)

Cloudflare Workers

Pricing model (Paid plan - $5/month base):

• Included: 10 million requests
• Additional: $0.50 per 1 million requests
• Included: 30 million CPU-milliseconds (30,000 CPU-seconds)
• Additional: $0.02 per 1 million CPU-milliseconds ($0.02 per 1,000 CPU-seconds)
• Bandwidth: Unlimited (included)

Cost for 1M requests/month:

• Monthly base fee: $5.00 (covers up to 10M requests)
• Request charges: $0 (within 10M included)
• CPU time: 1M requests × 5ms = 5,000 CPU-ms = 5 CPU-seconds (within 30,000 included)
• Bandwidth: 2MB × 1M = 2GB (included)
• Total: $5.00/month (or $0.50 per 1M if calculating marginal cost above free tier)

Marginal cost per 1M requests: $0.50 (if already paying base fee)

Vercel Edge Functions

Pricing model (Pro plan - $20/month):

• Included: 1 million edge function invocations
• Additional: $0.65 per 1 million invocations
• Execution limit: 50ms per invocation (wall time)
• Bandwidth: 1TB included in Pro plan

Cost for 1M requests/month:

• Pro plan base: $20.00/month (includes 1M requests)
• Additional requests: $0 (within 1M included)
• Bandwidth: 2GB (within 1TB included)
• Total: $20.00/month base (or $0.65 per 1M marginal cost)

Marginal cost per 1M requests: $0.65 (beyond included)

AWS Lambda (Node.js 18, 512MB memory)

Pricing model:

• Request charges: $0.20 per 1 million requests
• Compute charges: $0.0000166667 per GB-second
• Free tier: 1M requests + 400,000 GB-seconds per month (permanent)
• Data transfer: First 1GB free, then $0.09/GB (to internet)

Cost for 1M requests/month:

• Request charges: 1M × $0.20 = $0.20
• Compute: 1M requests × 5ms × 0.5GB = 2,500 GB-seconds × $0.0000166667 = $0.042
• Data transfer out: 2GB total = (2GB - 1GB free) × $0.09 = $0.09
• Cold start overhead: ~8% requests, 200ms init time = 80,000 × 0.2s × 0.5GB = 8,000 GB-seconds × $0.0000166667 = $0.13
• Total: $0.462 (or $0.00 if within free tier)

With free tier: $0.00 for first 1M/month Without free tier: $0.46 per 1M requests

Vercel Serverless Functions (Node.js)

Pricing model (Pro plan - $20/month):

• Included: 1,000 GB-hours execution time
• Additional: $0.18 per GB-hour
• Memory: 1024MB default
• No per-request charges
• Bandwidth: 1TB included

Cost for 1M requests/month:

• Pro plan base: $20.00/month
• Execution time: 1M × 5ms × 1GB = 5,000 GB-seconds = 1.39 GB-hours (within 1,000 included)
• Bandwidth: 2GB (within 1TB included)
• Total: $20.00/month base (within included limits)

Marginal cost per 1M requests: $0.25 (1.39 GB-hours × $0.18, if exceeding included)

Traditional CDN (CloudFront + S3 + Lambda)

Pricing model:

• CloudFront: $0.085 per GB (US/EU, first 10TB/month)
• S3 storage: $0.023 per GB/month
• S3 GET requests: $0.0004 per 1,000 requests
• Lambda: As calculated above

Cost for 1M requests/month (serving 2KB responses):

• CloudFront bandwidth: 2GB × $0.085 = $0.17
• S3 GET requests: 1M × $0.0004/1000 = $0.40
• Lambda (if dynamic): $0.46
• S3 storage: Negligible for 2KB objects
• Total: $1.03 per 1M requests

Cost Comparison Table (1M requests/month)

Platform	Base Fee	Cost per 1M Requests	Break-even Volume	Best For
Cloudflare Workers	$5/mo	$0.50 (marginal)	>100K requests/mo	High-traffic global apps
Vercel Edge Functions	$20/mo	$0.65 (marginal)	>100K requests/mo	Next.js apps, modern stacks
AWS Lambda (with free tier)	$0	$0.00	Low traffic (<1M/mo)	Development, side projects
AWS Lambda (no free tier)	$0	$0.46	Variable workloads	AWS ecosystem apps
Vercel Serverless	$20/mo	$0.25 (marginal)	Low-moderate traffic	Full-stack Next.js apps
CloudFront + Lambda	$0	$1.03	Traditional apps	Existing AWS infrastructure
Google Cloud Run	$0	$2.40	Containerized workloads	Container-based apps
DigitalOcean App Platform	$12/mo	$0 (up to 5M)	<5M requests/mo	Predictable costs

Real-World Cost Scenarios

Scenario 1: 1M requests/month (startup MVP)

• Cloudflare Workers: $5.00/month (base plan)
• Vercel Edge + Serverless (Pro): $20.00/month (base plan)
• AWS Lambda (free tier): $0.00/month
• AWS Lambda (no free tier): $0.46/month
• Recommendation: AWS Lambda free tier for MVPs, Cloudflare Workers for production

Scenario 2: 10M requests/month (growing SaaS)

• Cloudflare Workers: $5.00 + (9M × $0.50/1M) = $9.50/month
• Vercel Edge: $20.00 + (9M × $0.65/1M) = $25.85/month
• AWS Lambda: 10M × $0.46/1M = $4.60/month (beyond free tier)
• Hybrid (7M edge + 3M serverless): (7M × $0.50) + (3M × $0.46) = $4.88/month (+ base fees)
• CloudFront + Lambda: 10M × $1.03/1M = $10.30/month

Scenario 3: 100M requests/month (scale-up)

• Cloudflare Workers: $5.00 + (99M × $0.50/1M) = $54.50/month
• Vercel Edge: $20.00 + (99M × $0.65/1M) = $84.35/month
• AWS Lambda: 100M × $0.46/1M = $46.00/month
• Hybrid Architecture: $68.00/month (60% edge, 40% serverless)
• CloudFront + Lambda: 100M × $1.03/1M = $103.00/month

Scenario 4: 500M requests/month (high scale)

• Cloudflare Workers: $5.00 + (499M × $0.50/1M) = $254.50/month
• Vercel Edge: $20.00 + (499M × $0.65/1M) = $344.35/month
• AWS Lambda: 500M × $0.46/1M = $230.00/month
• Hybrid (70% edge, 30% serverless): $315.00/month
• CloudFront + Lambda: 500M × $1.03/1M = $515.00/month

Hidden Costs to Consider

1. Developer migration time: 2-4 weeks for non-trivial applications = $8,000-$16,000 in engineering costs (at $100/hour)
2. Edge-specific monitoring: Tools like Axiom, Baselime, or Datadog add $20-$100/month
3. KV storage operations:
   • Cloudflare KV: $0.50 per 10M reads, $5.00 per 1M writes
   • Vercel KV: $0.30 per 100K commands
   • High-write workloads can add $50-$200/month
4. Database connection pooling: Edge-compatible connection poolers (Supabase Supavisor, Neon) add $10-$50/month
5. Increased database egress: Queries from 50+ edge locations to single-region database can increase provider egress costs 3-5×
6. Rate limiting services: Edge rate limiting (Cloudflare, Fastly) adds $20-$100/month at scale

When Each Platform Makes Financial Sense

Choose Cloudflare Workers when:

• Traffic >10M requests/month (best per-request pricing)
• Global user base (latency reduction worth migration cost)
• Stateless workloads (auth, routing, transformation)
• Need unlimited bandwidth (included in pricing)

Choose Vercel Edge/Serverless when:

• Building with Next.js (seamless integration)
• Need hybrid edge + Node.js serverless (same platform)
• Moderate traffic (1-50M requests/month)
• Value developer experience over absolute cost optimization

Choose AWS Lambda when:

• Already on AWS (RDS, S3, etc.)
• Need mature ecosystem (monitoring, IAM, VPC)
• Variable traffic (pay per use, no base fee)
• <1M requests/month (free tier)

Choose Hybrid Architecture when:

• 60-80% of requests can be edge-cached or stateless
• Remaining 20-40% need database access or Node.js APIs
• Want optimal cost-performance balance
• Have engineering resources for multi-platform deployment

The decision isn't purely about per-request pricing. Factor in:

• Engineering time for migration ($8K-$16K one-time cost)
• Operational overhead (monitoring, debugging)
• Platform lock-in risks
• Future scaling needs

For most applications at 10-100M requests/month, Cloudflare Workers offers the best cost-performance ratio, but hybrid architectures (edge + regional serverless) provide the optimal balance of latency, cost, and functionality.

When NOT to Use Edge Computing

Edge computing isn't a universal solution. Skip it when:

1. Your database is single-region and latency-sensitive: Edge functions querying a centralized database are slower than serverless in the same region. Measured overhead: 100-250ms per query from distant edge locations. As PropertyHub learned, edge functions in Tokyo querying PostgreSQL in Virginia added 180-220ms vs 2-5ms for regional Lambda.

2. You need long-running operations: Edge runtimes limit execution time (50ms CPU on Cloudflare, 25s wall time on Vercel). Video processing, PDF generation, and ML inference belong in serverless or containers.

3. You depend on Node.js-specific packages: If your codebase relies heavily on native modules or Node APIs (fs, child_process, net, native crypto), the migration cost outweighs edge benefits. Budget 2-4 weeks for dependency refactoring.

4. Your traffic is regional: If 95% of users are in one geographic area, a single-region deployment is simpler and cheaper. Edge computing adds complexity without latency benefits.

5. You require strong consistency: Edge KV stores are eventually consistent (60-90s propagation). If your application can't tolerate stale reads, use regional databases with serverless compute.

6. Stateful operations with distributed locking: Session management, shopping cart state, or inventory reservations requiring coordination across 200+ locations introduce 80-120ms overhead and failure modes that don't exist in single-region architectures.

7. CPU-intensive workloads: Image processing, video encoding, or data transformations that take >50ms CPU time will timeout at edge. PropertyHub's image resizing failed because large images (>5MB) exceeded the 50ms CPU limit.

8. High connection count requirements: Edge functions from 50+ locations simultaneously connecting to your database will exhaust connection pools faster than regional serverless. Plan for 10-50× more connections.

Migration Checklist: Moving to Edge Runtimes

Based on three production migrations, here's the process that works:

Week 1: Audit and Planning

• List all server-side routes and middleware
• Identify Node.js API usage and incompatible packages
• Profile execution times (target <25ms for edge)
• Map database access patterns
• Choose edge-compatible alternatives for incompatible dependencies
• Calculate expected cost savings using pricing tables above

Week 2: Prototype and Test

• Set up local edge runtime (Miniflare for Cloudflare, Vercel CLI for Vercel)
• Migrate one low-risk route (e.g., health check endpoint)
• Test with production-like traffic using load testing tools
• Measure latency improvements with synthetic monitoring from multiple regions
• Verify Node.js API replacements work correctly

Week 3: Gradual Rollout

• Deploy edge functions behind feature flag
• Route 10% of traffic to edge, monitor error rates and latency
• Watch for connection pool exhaustion and database latency spikes
• Increase to 50%, then 100% over several days
• Keep serverless fallback for 2-4 weeks

Week 4: Optimization

• Analyze edge function performance metrics by region
• Optimize cold start times (minimize dependencies, tree-shake imports)
• Implement caching strategies (KV, Cache API) with appropriate TTLs
• Document edge-specific patterns for team (import transformations, API limitations)
• Set up alerting for edge-specific failure modes (KV propagation lag, connection timeouts)

Real-World Performance: Before and After

Here are actual metrics from a Next.js e-commerce application migrated to Vercel Edge Functions:

Before (Serverless, us-east-1)

• Global median TTFB: 420ms
• P95 TTFB: 890ms
• Cold start rate: 12%
• Monthly cost: $45 (Vercel Pro)

After (Edge Functions + Serverless hybrid)

• Global median TTFB: 78ms (81% improvement)
• P95 TTFB: 180ms (80% improvement)
• Cold start rate: <1%
• Monthly cost: $48 (minimal increase)

The key insight: We didn't move everything to edge. Authentication, routing, and static content generation run at the edge. Product data fetching and checkout logic remain in serverless functions co-located with the database.

The Future: Edge-First by Default

Frameworks are moving toward edge-first architectures. Next.js 13+ defaults to edge runtime for middleware. Remix supports edge deployment out of the box. SvelteKit has first-class Cloudflare Workers support.

This shift reflects a fundamental truth: for globally distributed applications, edge computing isn't an optimization — it's table stakes. Users expect sub-second load times regardless of location. Edge runtimes make that possible without managing infrastructure in 20+ regions.

The question isn't whether to adopt edge computing, but which parts of your application benefit most from edge deployment. Start with authentication and routing. Move to edge-native databases for read-heavy workloads. Keep complex business logic in serverless or containers until edge runtimes mature.

The architecture that works best in 2024 is hybrid: edge for the hot path, serverless for data access, containers for heavy lifting. Understanding where each layer excels — and more importantly, where it fails — is the difference between a fast application and a fast, cost-effective, maintainable application.