Edge Compute vs Origin Compute

When to run code at the edge (Cloudflare Workers, Vercel Edge, Fastly Compute@Edge) vs at a regional origin (Lambda, App Service, VPS).

Cloud ComparisonIntermediate

Why

Edge compute runs in 100s of POPs near users (sub-50ms globally) with tiny cold starts, ideal for auth, rewriting, personalization, and small API calls. Origin compute runs in one region with full runtime (Node, Python, DB connections) but higher latency for distant users.

Edge is limited (no DB pooling, small memory); origin is unlimited.

When

Use edge for per-request logic that must be fast everywhere (auth tokens, A/B routing, geo redirects, feature flags). Use origin for stateful work (DB transactions, heavy compute, long-running jobs, ML inference).

Hybrid: edge does auth + routing, origin does the real work — this is the modern pattern.

How

1. Identify per-request logic that is latency-sensitive (auth, routing, personalization). 2. Move it to an edge function (Workers, Vercel Edge, Fastly). 3. Keep stateful/heavy logic at a regional origin (Lambda, App Service, VPS). 4. Edge calls origin for data; cache responses at the edge. 5. Use a global DB with edge reads (Turso, D1) or edge-to-origin for writes. ```text Edge (Workers): auth → check JWT → route to origin or serve cached Origin (Lambda): DB query → business logic → response ```

Example

Edge function (Cloudflare Workers) that validates a JWT and caches an origin response: ```ts // workers/api.ts export default { async fetch(req, env) { const token = req.headers.get("Authorization")?.slice(7); const claims = await validateJwt(token); // WebCrypto, no Node if (!claims) return new Response("unauthorized", { status: 401 }); const cache = caches.default; const key = new Request(req.url, req); let res = await cache.match(key); if (!res) { res = await fetch(env.ORIGIN_URL + "/api/data", { headers: { Authorization: token } }); res = new Response(res.body, res); res.headers.set("Cache-Control", "s-maxage=60"); ctx.waitUntil(cache.put(key, res.clone())); } return res; }, }; ``` The edge handles auth + cache (sub-50ms globally); the origin does the DB work once per cache window.

Common Problems

⚠Edge cannot hold DB connections (no TCP pooling in V8 isolates) — use HTTP-based DB (Turso, D1, PlanetScale HTTP API) or call the origin for DB work.
⚠Edge runtime lacks Node built-ins — polyfill or move that logic to origin; check the runtime's API list before writing.
⚠Edge + origin doubles observability surface — use a distributed tracing header (traceparent) and one APM that ingests both (Datadog, Honeycomb).

Best Practices

✓Put auth, routing, and A/B at the edge (fast everywhere); put DB transactions and heavy compute at a regional origin — the hybrid is the sweet spot.
✓Cache origin responses at the edge with s-maxage so the origin is hit once per cache window per region, not per user.
✓Use a global edge database (D1, Turso) for reads so the edge does not need to call the origin for simple queries.

FAQ

What is Edge Compute vs Origin Compute and what problem does it solve?

When to run code at the edge (Cloudflare Workers, Vercel Edge, Fastly Compute@Edge) vs at a regional origin (Lambda, App Service, VPS). It lets developers deploy, store, and scale without self-managing infrastructure — a core reference for cloud service selection.

How do I get started with Edge Compute vs Origin Compute in 5 minutes?

Two steps to run it: (1) Identify per-request logic that is latency-sensitive (auth, routing, personalization).; (2) Move it to an edge function (Workers, Vercel Edge, Fastly).. Validate on the free tier first, then wire into production.

What is the #1 pitfall with Edge Compute vs Origin Compute?

The most frequent issue is: Edge cannot hold DB connections (no TCP pooling in V8 isolates) — use HTTP-based DB (Turso, D1, PlanetScale HTTP API) or call the origin for DB work.. Run a pre-launch checklist item by item, and add policy/config scanning in CI.

What are the best practices for Edge Compute vs Origin Compute?

Best practices for Edge Compute vs Origin Compute include: Put auth, routing, and A/B at the edge (fast everywhere); put DB transactions and heavy compute at a regional origin — the hybrid is the sweet spot.; Cache origin responses at the edge with s-maxage so the origin is hit once per cache window per region, not per user.; Use a global edge database (D1, Turso) for reads so the edge does not need to call the origin for simple queries.. The first one — "Put auth, routing, and A/B at the edge (fast everywhere); put DB transactions and heavy compute at a regional origin — the hybrid is the sweet spot." — should be a team default baked into your IaC templates.

How do I control cost and avoid bill surprises with Edge Compute vs Origin Compute?

Three ways to prevent overspend: (1) tag every resource with env/team and enable billing alarms; (2) set budget thresholds to trigger Slack/email alerts; (3) review idle resources in Cost Explorer regularly and clean them up. Most Edge Compute vs Origin Compute options offer a free tier — validate within free quota before scaling.