The Edge Hype Machine
Vercel, Cloudflare, Deno Deploy — everyone's selling you on edge functions. "Run your code at the edge, close to your users, for blazing-fast response times!" And look, the technology is genuinely impressive. But after deploying edge functions in five production projects, we have a more measured view than the marketing would suggest.
Here's the honest assessment: edge functions are fantastic for a narrow set of use cases and unnecessary for most web applications.
Where Edge Functions Genuinely Help
The single biggest win we've seen from edge functions is personalization at the CDN layer. For an e-commerce client, we use Vercel Edge Middleware to handle geo-based redirects, A/B test routing, and authentication token verification. These operations need to happen before the page loads, and doing them at the edge (instead of routing to a single origin server) shaves 100-300ms off the response time for users in regions far from the origin.
Another genuinely good use case: API response transformation at the edge. We have a client whose API returns responses in a verbose format for internal consumers. For their public website, we run an edge function that transforms and compresses the response. This saves bandwidth and reduces payload size without changing the origin API.
Feature flags and gradual rollouts are also a natural fit. Checking a feature flag and routing traffic accordingly is a lightweight operation that benefits from edge execution. We use LaunchDarkly's edge SDK for this and it works well.
Where Edge Functions Fall Down
The moment you need to talk to a database, the edge advantage mostly disappears. Your edge function runs in Mumbai, close to your Indian user. Great, 20ms of network latency saved. But then it needs to query your PostgreSQL database in us-east-1, adding 200ms of latency. The total is 220ms. A regular serverless function in us-east-1 would have been 200ms + 100ms network = 300ms. You saved 80ms. For most applications, that's not worth the constraints.
And the constraints are significant. Edge runtimes have limited APIs — no Node.js filesystem, limited crypto, restricted fetch behavior. Many npm packages don't work because they depend on Node.js APIs. Execution time is limited (Vercel Edge Functions have a 25-second timeout for the Hobby plan). Cold starts are lower than traditional serverless, but they still exist. And debugging is painful — you can't just attach a debugger to a function running in 30 data centers simultaneously.
The Database Problem Is Getting Solved (Slowly)
This is changing. Neon's serverless PostgreSQL supports edge connections. PlanetScale (before their free tier debacle) had edge-compatible MySQL. D1, Cloudflare's SQLite-at-edge, is interesting for certain use cases. Turso (libSQL at the edge) is probably the most promising approach — they replicate your database to edge locations, so reads are truly local.
We've tested Turso for a read-heavy content site and the results are promising: p50 read latency of 8ms compared to 45ms for a centralized database. But for write-heavy applications, you still have the replication lag issue, and edge databases are a newer technology with less battle-testing than centralized PostgreSQL.
Our Recommendation
Use edge functions for: authentication/authorization checks, redirects and rewrites, A/B test routing, geolocation-based personalization, and response transformation. Don't use edge functions for: anything that needs a database query (unless you've committed to an edge-compatible database), complex business logic, or anything that needs npm packages with Node.js dependencies.
For most of our client projects in India, where the majority of users are domestic and the server is in Mumbai (ap-south-1), edge functions provide minimal benefit because the origin is already close to users. We save them for projects with globally distributed user bases where the latency savings are meaningful.