Back in January, we had a user in Melbourne complaining about 800ms API response times. Our API runs on a single-region setup in us-east-1 — has done for three years, works fine for most of our US/UK users, never really bothered us enough to fix.
Then we added an AI-assisted feature (a real-time text classification thing, nothing fancy) and suddenly the latency problem became impossible to ignore. Running inference in one AWS region and serving users in Sydney, Mumbai, or São Paulo? That’s a bad time.
So I spent the better part of February testing whether edge deployment was actually the answer or just the thing everyone on Twitter kept telling me was the answer.
Short version: it helped. But not in the ways I expected.
The Edge Runtime Reality Check
Let me back up a second. When people say “edge computing,” they’re usually collapsing several distinct things into one label: CDN-adjacent compute (Cloudflare Workers, Fastly Compute), platform-specific edge functions (Vercel Edge Functions, Netlify Edge Functions), or the growing category of edge-native databases. These aren’t the same thing, and the confusion causes real problems in team conversations.
I tested Cloudflare Workers and Vercel Edge Functions for roughly two weeks each. My team is five people — three engineers, one designer, one product — and we run a B2B SaaS tool for content operations teams. Our stack is Next.js on the frontend, a Node API on the backend, Postgres on Supabase.
What surprised me was how much the runtime constraints have loosened since 2024. Cloudflare Workers now has decent support for Node.js APIs — the gap between what you can do in Workers versus a traditional Lambda is noticeably smaller than it was eighteen months ago. The 128MB memory limit is still there (technically 512MB on the Unbound plan), but I hit it less often than I expected for our API workloads.
One thing I noticed: the cold start narrative is mostly dead at this point. Workers stay warm in a way that Lambdas historically didn’t, and Vercel’s fluid compute work has made even their non-edge functions faster to initialize. Edge wins on consistent tail latencies more than raw cold start avoidance — which is actually a more useful property for real users than the cold start framing suggests.
If you’re still avoiding edge runtimes because of the 2022 version of this conversation, the constraints have genuinely changed. Worth re-evaluating.
What It Actually Fixed (And Where It Got Awkward)
The latency wins were real. Our P50 API response time for users outside North America dropped from around 700–900ms to 90–140ms after moving our lightweight endpoints to Workers. That’s not a rounding error — that’s the difference between a feature feeling snappy and feeling broken.
But not everything we run belongs at the edge. Our heavier routes — the ones hitting Postgres, doing file processing, running longer computations — those stayed in us-east-1. And they probably should. Edge compute is cheap and fast for stateless, low-latency work. It gets awkward fast when you need to talk to a centralized database that’s already 200ms away from your edge node.
I thought edge databases would solve everything. And — partially, they do?
We tried Cloudflare D1 for a read-heavy cache layer. The developer experience has gotten genuinely good. You write SQL, you deploy it alongside your Worker, it mostly just works. Replication latency across regions was better than I expected — usually under a second for propagation. For our use case (caching processed content metadata that updates a few times a day), this was totally fine.
For anything transactional or strongly consistent, though, I wouldn’t trust it yet. As of February 2026, I wouldn’t put critical write paths through D1 without a fallback plan. Maybe that changes by the time you read this.
The Mistake I Made on a Friday Afternoon
I pushed an edge function update at 4pm on a Friday — classic — that moved our user authentication check to the edge layer. The logic seemed simple: intercept requests, validate JWTs, route accordingly. What I did not account for was that our JWT validation library was using Node’s crypto module in a way that Cloudflare Workers didn’t support, even with the compatibility flags I had set.
This broke auth for about 12 minutes before I caught it. Not catastrophic, but embarrassing. The error message wasn’t helpful — a generic runtime failure that didn’t identify which import was the problem. I spent 45 minutes in a GitHub issue thread for the library before finding the relevant Workers compatibility note buried in a comment.