Edge Functions Are Not a Personality
Edge functions are a deployment target with real constraints — excellent for auth, routing, A/B testing. Wrong for database queries or persistent connections.
Edge functions shipped as a brand before they shipped as a technology. The pitch — "run code closer to your users, everywhere on the planet" — is real, but the limitations got buried in the launch blog posts. Teams adopted edge functions as an architectural philosophy, not a deployment decision, and ended up with systems that timeout trying to connect to a Postgres database that lives in us-east-1 anyway.
Edge functions are a tool with a specific shape. Here's what that shape actually is.
What Edge Functions Are Actually Good For
Geolocation-based routing. Cloudflare Workers get the user's country from request.cf.country. Vercel Edge Middleware gets it from the x-vercel-ip-country header. Both are available before your origin server ever sees the request. Redirecting example.com to example.com/en-gb or example.com/de based on country, without a round trip to your app server, is a legitimate win. Response time drops from 200ms to under 20ms for that redirect.
Auth token validation. Verifying a JWT at the edge — checking signature, expiry, and claims — is a pure CPU operation with no I/O. Edge runtimes handle this well. You can reject unauthenticated requests before they hit your origin, cutting unnecessary load and giving users a faster 401 response.
A/B testing without cold starts. Edge functions stay warm in a way Lambda functions don't. For traffic splitting — send 50% of users to variant B by setting a cookie and rewriting the URL — this works well. The function is stateless, the operation is fast, and you avoid the Lambda cold start that makes A/B testing at the CDN layer painful with traditional serverless.
Request/response transformation. Adding security headers, rewriting URLs, stripping internal headers before they reach the client — all I/O-free operations that run well at the edge.
What They're Bad For
Database connections. This is the big one. PostgreSQL, MySQL, and most traditional databases use persistent TCP connections. Edge runtimes — Cloudflare Workers, Vercel Edge, Deno Deploy — run on V8 isolates, not Node.js. They have no persistent connection pool. Every request either opens a new connection (expensive, often rate-limited by the database) or goes through an HTTP-based proxy like PlanetScale's serverless driver or Neon's HTTP API.
If your edge function makes a database call, you've likely eliminated the latency benefit. The database is in a single region. The function ran "at the edge" only to then make a full round trip back to us-east-1. You've added a hop.
Heavy computation. CPU time limits are real. Cloudflare Workers have a 10ms CPU time limit on the free plan (50ms on paid). Vercel Edge has similar constraints. Anything involving parsing large documents, running ML inference, or processing binary data will hit these limits. These runtimes are designed for fast, light operations — not for work that belongs on a compute instance.
File system operations. There is no file system. No fs.readFile, no temp directories, no writing files. If your function needs to read a config file or write a cache artifact to disk, you're not running in a compatible environment. Use object storage with an HTTP API instead.
npm packages that use Node.js APIs. The edge runtime is not Node.js. Packages that import node:crypto, node:buffer beyond the polyfilled version, or native addons will fail at runtime. Cloudflare Workers has a compatibility layer for some Node built-ins, but it's a subset. Check the edge-runtime compatibility table before importing.
The Vercel vs Cloudflare Workers Distinction
Vercel Edge Middleware and Cloudflare Workers are often discussed interchangeably. They aren't the same.
Vercel Edge runs your middleware before routing to your Next.js or other origin. It's tightly coupled to Vercel's infrastructure. The runtime is a subset of the Web standard APIs. It's convenient if you're already on Vercel, constrained if you're not.
Cloudflare Workers runs at Cloudflare's edge nodes globally, with access to KV storage (eventually consistent, millisecond reads), R2 (S3-compatible object storage), and Durable Objects (strongly consistent stateful objects, but with their own complexity). Workers gives you more surface area — and more ways to misuse it.
Neither is a backend. Both are traffic handling layers.
The Real Question
Before deploying to edge, ask: does this function do anything that requires I/O beyond the request itself? If yes, the edge runtime is probably not the right host. A standard serverless function in the same region as your database will outperform an edge function that has to call back to that region anyway.
Edge is for the boundary between the internet and your system — auth, routing, transformation, traffic shaping. It's not a general-purpose compute platform, and treating it like one creates systems that are fast in marketing decks and slow in production.