Edge computing made a real promise: run your code in a data center close to the user instead of one central region, and shave the round-trip time that physics otherwise charges you. For static content and simple logic, that promise mostly holds. For anything that touches a database, it's easy to optimize the wrong 10 milliseconds.
Where the time actually goes
A typical API request spends its time roughly like this: network round-trip to the server, application logic, one or more database queries, then the trip back. Moving the application logic to the edge only shrinks the first and last pieces. If your database lives in a single region and your edge function now has to reach across the globe to query it, you can end up with a slower request than before — the edge function itself runs fast, then sits there waiting on a database connection that has to cross the same distance it used to.
This isn't an argument against edge functions. It's a reminder that "closer to the user" only helps the parts of the request that were actually network-bound to begin with.
The actual fix is usually data locality
If a query is the bottleneck, the fix is rarely "make the function that calls it run somewhere fancier." It's making the data itself available closer to where it's queried — read replicas in multiple regions, edge-compatible caching for data that tolerates some staleness, or accepting that some operations are inherently regional and routing accordingly. Edge compute and edge data are two different problems, and solving the first one without touching the second often just relocates where the latency shows up in your trace, not how much of it there is.
A useful question before reaching for the edge
Before moving a function to the edge, profile what it's actually waiting on. If most of its time is spent waiting on a database query or a third-party API in a fixed region, running the function itself closer to the user buys you very little — the slow part hasn't moved. Edge functions are a good answer to "the network hop is the bottleneck." They're not an answer to "the query is slow," and conflating the two is one of the more common ways edge migrations under-deliver on their promised latency wins.
