Edge Computing for Builders

Serverless functions (AWS Lambda, Vercel Serverless Functions) run in a single AWS region or a small set of regions. When a user in Sydney hits your US-East serverless function, they experience 200-400ms of latency just for the round-trip network time. Edge functions run in the provider's global network — Cloudflare Workers run across 300+ locations worldwide, so the same Sydney user is served from a nearby Cloudflare PoP with 15-30ms latency. The tradeoff is constraints: edge runtimes run a subset of the Web Platform APIs (no Node.js built-ins like fs, crypto is Web Crypto only) and have stricter execution time limits. Edge is best for latency-sensitive lightweight operations; serverless is best for CPU-intensive or I/O-heavy operations with Node.js dependencies.

Vercel Edge Middleware runs before every request in your Next.js application and can inspect and rewrite the request before it hits your pages or API routes. Common use cases: authentication (validate a JWT and redirect unauthenticated users before the page server-renders), A/B testing (serve different page variants to different users without client-side flicker), feature flags (route users to different versions of a page based on their cohort), geolocation-based content (serve different content or currency based on the user's country), and bot protection (block or challenge requests that look like scraper traffic). Edge Middleware runs in under 5ms for simple operations and does not add meaningful latency to your page renders.

Traditional connection-pooled databases (PostgreSQL with pg) do not work well at the edge because each edge function invocation creates a new connection, and databases have connection limits. The solutions: use an HTTP-based database client that works in edge runtimes (Supabase, PlanetScale, Turso, Neon all offer edge-compatible drivers), use a connection pooler like PgBouncer or Supabase's connection pooler between your edge function and Postgres, or cache database results at the edge using the Cache API and refresh them periodically. For most edge use cases, the pattern is: check the edge cache first, fall back to your database only on cache misses, and store the result so the next request is served from cache.

Edge runtimes have meaningful constraints compared to Node.js. No file system access — you cannot read files from disk. No Node.js native modules — anything that uses native bindings (most image processing libraries, crypto with native bindings) does not work. Execution time limits — Cloudflare Workers allows 50ms CPU time on the free plan, 30 seconds on paid. Memory limits — typically 128MB, which constrains what you can load into memory. Cold starts — though usually under 5ms at the edge vs 200-500ms for Node.js serverless. No long-running connections — no WebSockets in most edge runtimes (Cloudflare Durable Objects is the exception). Design your edge functions to be fast, stateless, and lightweight — delegate heavy computation to a traditional serverless function.

Edge computing pricing is generally very affordable for most production applications. Cloudflare Workers: 100,000 requests per day free, then $5/month for 10 million requests. Vercel Edge Middleware: included in all Vercel plans with no additional per-request charge. Deno Deploy: 1 million requests per month free. The economics are more favourable than traditional serverless because edge functions are extremely fast (low CPU time) and the provider operates at massive scale. For a typical SaaS application adding edge middleware for auth and personalisation, the monthly cost increase is often $0 (free tier) or under $5. The cost constraint for edge computing is usually developer time understanding the new model, not the infrastructure bill.