Edge functions win when the work is small, stateless, and needs to happen close to the user. They lose when you need a real database connection, a long-running process, or a debugger that isn’t three cloud dashboards deep.

Where edge functions actually win

• Auth checks and redirects. Validate a JWT, redirect based on geolocation or A/B bucket, rewrite a URL. All of this runs in single-digit milliseconds and needs no backend round trip.
• Response header manipulation. Add security headers, set cache directives, strip internal fields, before the response ever reaches a full server.
• Personalization at the cache boundary. Inject a user’s name into an otherwise-cached HTML shell without busting the whole page cache.
• A/B testing. Split traffic at the edge before it hits your origin, so both variants can still be cached.

These share a trait: low compute, no long-lived connections, correctness doesn’t depend on being near your database.

Where edge functions cost you more than they save

• Anything hitting a traditional database. Your Postgres instance lives in one region. A function running in 300 edge locations still has to make that same slow round trip back to the database — you’ve added a hop, not removed one.
• Long computations. Most edge runtimes cap execution time (often around 30-50ms of CPU on the free tiers, longer on paid, but still far short of a normal server). Image processing, PDF generation, and heavy JSON transforms don’t belong there.
• Anything needing full Node APIs. Edge runtimes are usually a V8 isolate, not Node. No fs, limited crypto, no native modules. You’ll hit “Module not found” errors that don’t reproduce locally because your local dev server is running full Node.
• Debugging. Cold logs, no attached debugger, and stack traces that reference minified edge bundles. A bug that takes 5 minutes to find with console.log and a local server can take an hour when it only reproduces at the edge in production.

The debugging cost, specifically

This is the part teams underestimate:

Error: fetch failed
    at Object.fetch (edge-runtime-internal)

That’s the entire stack trace you get in some edge environments for a failed upstream call. No line number in your code. You end up bisecting your function by commenting out chunks and redeploying, because there’s no local repro that matches the edge runtime exactly.

A simple decision rule

The practical path

Build the logic as a normal serverless or server function first, where you have a debugger and fast iteration. Move it to the edge only after it’s correct and you’ve confirmed it doesn’t need anything the edge runtime lacks. Moving early just means debugging the same bug twice — once in your head, once against a runtime that won’t tell you what’s wrong.