The Edge vs the Origin: Where Your Code Should Actually Live
Every platform wants you to move your code to the edge. For some things that is excellent advice. For others it is a trap. Here is how we decide.
The marketing for edge compute has been loud for several years now. Every hosting platform has an edge offering, most framework documentation recommends the edge runtime by default, and "deploy to the edge" has become shorthand for "you are doing it right".
It is true that running code close to users can make things faster. It is also true that moving the wrong workload to the edge can make things slower, more complex, and more expensive than leaving it where it was. The decision is not "edge good, origin bad". It is "which parts of my system benefit from being close to users, and which parts do not".
Here is how we think about it.
What Edge Actually Gives You
Two things, mostly.
Lower latency on the first byte. Code running in an edge location physically closer to the user responds faster, because the packets travel less distance. This matters for interactive workloads where every millisecond is felt — authentication redirects, personalisation logic, cache lookups, A/B test assignment.
Distributed execution without managing regions. Instead of picking one or two regions for your origin and routing traffic there, edge platforms run your code in dozens of locations automatically. For global user bases, this is a real operational simplification.
What edge does not give you: more compute, better access to your data, or cheaper execution at scale. Those are problems where the edge is usually worse, not better.
The Latency Argument, Nuanced
The "edge is faster" story is mostly about the first byte. Whether it is faster end-to-end depends on where your data lives.
A request that runs entirely at the edge, with all its dependencies already cached or computed at the edge, is as fast as anything can be.
A request that runs at the edge but needs data from a database in us-east-1 is not faster than one that runs in us-east-1 directly. It is slower, because the edge function now has to make a cross-region call to the database, which takes longer than having the whole operation in the same region.
This is the trap. Most applications have their data centralised somewhere. Moving the compute to the edge without moving the data doesn't move the bottleneck. It just adds a hop.
Cloudflare's documentation on edge latency is honest about this, and their answer — co-locate data with compute via D1, Durable Objects, KV — is correct. The problem is that most apps have not made that move and are not about to.
Where Edge Is Genuinely The Right Answer
Redirects and rewrites. Sending an old URL to a new one, or routing based on a cookie or geolocation — this is lightweight, latency-sensitive, and needs no database access. It is the canonical edge use case.
Authentication gates. Checking a session cookie, validating a JWT, redirecting unauthenticated users — runs in milliseconds, happens before the expensive work, makes the whole request faster if it is rejected.
A/B test assignment. Deciding which variant a user should see, persisting the choice in a cookie, letting the downstream render pick up from there. Edge-friendly because the logic is local and the result is a small amount of state.
Caching layers. Static and dynamic content cached at the edge, with the edge function deciding whether to serve from cache or go to origin. Most modern frameworks do this automatically now, and it is where the most obvious edge wins come from — both for latency and for your Core Web Vitals scores.
Personalised static content. Taking an otherwise-static page and injecting a small amount of user-specific content at the edge — the user's name in a greeting, a localised price, a feature flag state. Much faster than making the page fully dynamic, and still personalised.
Geo-routing and compliance. Sending European users to European infrastructure, US users to US infrastructure — this is trivially done at the edge and much harder at the origin.
Where Edge Is Usually Wrong
Database-heavy endpoints. Any handler that does multiple database queries belongs close to the database. The latency of multiple round trips across the world dominates any savings from running closer to the user.
Long-running operations. Edge runtimes typically have strict CPU and wall-clock limits. If your task takes more than a few hundred milliseconds of compute, the edge is not the place for it.
Heavy computation. Image processing, video encoding, machine learning inference, large data transformations. The edge is designed for short, low-CPU tasks. Anything else should run elsewhere.
Stateful sessions. Anything that needs to maintain state across requests is awkward at the edge, unless you specifically design for it using primitives like Cloudflare Durable Objects or similar. For most apps, it is easier to keep stateful logic at the origin.
Code that depends on libraries built for Node.js. Some edge runtimes are V8-based with a reduced API surface. Libraries that use Node's fs, child_process, or native modules will not run. If your server code depends on these, moving it to the edge involves rewrites.
The Hybrid Model
In practice, the right answer for most applications is not "everything at the edge" or "everything at the origin". It is a split:
- Routing, authentication gates, and cache lookups at the edge.
- Data-heavy application logic at the origin, close to the database.
- Background jobs and heavy compute at the origin or in dedicated workers.
- Static assets at the edge via a CDN, which is largely automatic.
Most modern frameworks — Next.js, Remix, SvelteKit — support this split natively. You can opt into the edge runtime on a per-route basis, and leave the rest on a regional server runtime. This is the most flexible posture and the one we reach for by default; our post on why your Next.js app is slower than it should be covers the framework-specific details in more depth.
The Cost Side
Edge compute is not automatically cheaper than origin compute. Per-request, it is often more expensive, because the platform is running code in more locations simultaneously.
For a typical application, the cost delta is not large enough to matter. For very high-volume workloads, it can be. Vercel's pricing model makes the edge and origin costs explicit, and it is worth doing the math for your specific traffic pattern.
The related cost consideration is egress. Data moving out of a cloud provider to an edge platform is not free, and for data-heavy applications the egress cost can exceed the compute savings. This is a less visible but very real part of the picture.
How We Actually Decide
The question we ask first is: "does this handler need data from my origin to do its job?"
If the answer is no — it is a redirect, a rewrite, an auth check, a simple transformation — the edge is probably the right home.
If the answer is yes — it needs to read from the database, call internal services, or maintain session state — start at the origin and only move to the edge if you have a specific reason and the data architecture to support it.
The second question is: "how long does this take to run?"
If it takes more than a couple of hundred milliseconds of CPU, or involves multiple round trips, or relies on libraries that are not edge-compatible, leave it at the origin.
These two questions catch the overwhelming majority of "should this be at the edge" decisions, and following them avoids the two biggest failure modes — moving data-heavy workloads to the edge and making them slower, or moving compute-heavy workloads to the edge and running into runtime limits.
The Direction of Travel
The edge runtime ecosystem is improving. Data primitives closer to the edge (Cloudflare D1, Fauna, Planetscale with Vitess) are reducing the "compute is close but data is far" problem. Runtimes are getting more capable. The list of things that genuinely belong at the edge is growing.
That said, the default answer for new applications is still: start with a regional deployment, move specific things to the edge as you identify them, and do not pretend that edge is free.
Deciding whether a particular piece of your system should go to the edge? Get in touch — we are happy to talk through the specifics.