When Vercel Edge Functions Are Worth the Constraints (and When They Aren't)

You have a redirect rule, a cookie check, or a geolocation header that needs to run on every request before it reaches your app. Running that logic in a regional serverless function adds a round trip to one data center. Running it in the browser is too late. This is the gap Vercel Edge Functions fill — but they come with a runtime that will surprise you if you treat them like Node.js.

The thesis is simple: Edge Functions are the right tool for small, fast, request-shaping logic, and the wrong tool for almost everything else. Knowing where the line sits saves you a painful rewrite.

What the edge runtime actually is

Edge Functions run in a lightweight V8-based runtime — the same class of environment as the browser's JavaScript engine — not a full Node.js process. That choice is deliberate: a minimal runtime starts fast, so cold starts are measured in milliseconds rather than the hundreds of milliseconds a Node.js function can take. Vercel also deploys these functions to many points of presence, so your code executes in a data center physically close to the user instead of one fixed region.

The trade-off is API surface. You get standard Web APIs — fetch, Request, Response, Headers, crypto (the Web Crypto version), streams, and timers. You do not get fs, child_process, raw TCP sockets, or most Node-specific built-ins. Any npm package that transitively depends on those will fail to deploy or crash at runtime. Before committing, audit your dependencies: auth libraries, database drivers, and image-processing packages are the usual offenders.

A worked example: geo-aware middleware

The most common production use is middleware — intercepting a request before it hits your pages or API routes. In a Next.js project, create middleware.ts at the project root (next to pages or app, not inside them):

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export const config = {
  matcher: ['/store/:path*'],
};

export default function middleware(req: NextRequest) {
  const country = req.geo?.country ?? 'US';

  // Redirect EU visitors to the regional storefront
  if (country === 'DE' || country === 'FR') {
    const url = req.nextUrl.clone();
    url.pathname = `/eu${url.pathname}`;
    return NextResponse.redirect(url);
  }

  // Otherwise continue, tagging the request for downstream logging
  const res = NextResponse.next();
  res.headers.set('x-visitor-country', country);
  return res;
}

The matcher config restricts execution to /store/* paths, so you don't pay the (small) latency cost on static assets or unrelated routes. Middleware in Next.js runs on the edge runtime by default. Note that req.geo is populated by Vercel's platform in production; locally it will be undefined, which is why the fallback to 'US' matters.

To try it locally, run vercel dev from the project root with the Vercel CLI installed (requires Node.js and a linked project via vercel link). The plain next dev command runs middleware too, but vercel dev more closely simulates the platform environment. After deploying, open the Functions tab in the Vercel dashboard and confirm the function is labeled with the Edge runtime — if it shows a regional serverless function instead, something in your config overrode the default.

The constraints that bite in production

Three limits shape what you can build:

• Execution time. Edge Functions have a much tighter wall-clock budget than regional serverless functions. The exact limit depends on your plan and has changed over time, so check the current Vercel docs rather than relying on a number from a blog post — including this one. The practical rule: if you're awaiting more than one or two fast network calls, you're in the wrong runtime.
• Memory and bundle size. The code bundle must be small. Heavy dependencies (ORMs, large validation libraries) can push you over the size limit or slow cold starts enough to defeat the purpose.
• No Node.js APIs. As covered above, this eliminates whole categories of libraries. A Postgres driver that needs raw TCP won't work; you'd need a driver that speaks HTTP or WebSockets instead.

There's also a subtler issue: "close to the user" is not the same as "close to your data." If your edge function makes a call to a database in us-east-1 and your user is in Sydney, the function runs near Sydney but the query still crosses the Pacific. Edge logic that depends on a single-region database can be slower than just running everything in the database's region. Edge works best when the function is self-contained (redirects, rewrites, header logic, JWT verification with a public key) or talks to globally replicated data.

A quick decision rule

Reach for Edge Functions when the work is: reading cookies or headers, verifying a token, redirecting or rewriting the URL, A/B test bucketing, or personalizing a cached response. Reach for a regional Serverless Function when the work is: querying a database, rendering with heavy libraries, calling multiple third-party APIs, or anything needing Node.js built-ins.

To verify a deployment behaves as expected, check the response headers in your browser's network inspector — Vercel sets routing and cache headers such as x-vercel-cache and an x-vercel-id containing the region code, which tells you where the request was actually handled. If the region code isn't near your test location, or your middleware isn't firing, re-check the matcher config first; an overly narrow or broad matcher is the most common cause.

Start with one small piece of request-shaping logic — a locale redirect is a good candidate — deploy it, and measure the latency difference against doing the same thing in a regional function. That measurement, not the marketing page, should drive where the rest of your logic lives.