Vercel Edge Functions Are Deprecated and That Was Right

Node Is the Default Now and Edge Is the Opt In#

The pitch in 2022 was that the edge is where serious code ends up and a single region is the thing you migrate away from. Open the Edge runtime docs today and the guidance waiting there is the reverse, recommending you migrate "from edge to Node.js for improved performance and reliability".

The sharpest statement of that inversion is not in the prose. It is a comment inside the code sample on the same page.

export const runtime = 'edge'; // 'nodejs' is the default

Node is the default. Edge is a flag you opt into, from documentation that would rather you did not. Vercel Functions run in a single region by default, iad1, which is Northern Virginia.

A platform that sold globally distributed compute now hands you one building in Virginia unless you ask for something else.

The Runtime Survived but the Product Did Not#

Most of the confusion lives here, and precision matters because a reader who panics at this point deletes code that works. The Edge runtime was not removed. It has a live docs page updated in June 2026 and still sits among the eight official runtimes.

What ended was the product and the default. The deprecation changelog names both replacements without ceremony.

• Edge Middleware became Vercel Routing Middleware, described as a new infrastructure primitive rather than a runtime choice.
• Edge Functions became Vercel Functions using the Edge runtime, folded into one product with one pricing model and one set of regions.

A thread on r/nextjs asking whether Vercel is giving up on the edge runtime still ranks on the first page of Google for this exact question, three replies deep and unresolved. The answer is no, and also yes. The runtime is fine, and the idea that you should reach for it first is finished.

Nothing about this is urgent. Existing edge routes keep running, and the migration for most of them is deleting one line, which you can find in a few seconds.

grep -rnE "runtime\s*=\s*['\"]edge['\"]" . --include='*.ts' --include='*.tsx' --include='*.js'

Whether deleting it is worth doing depends on what the edge runtime has been costing you, and that bill is itemized on its own docs page. These are the constraints Node does not have.

That list was the trade you accepted in exchange for running near the user. The rest of this post is about why the thing you were buying turned out not to be for sale.

Every Round Trip Became a Continent#

Moving compute to the edge does not change how long a query takes. It changes what a round trip costs, and that quietly flips which number is worth optimizing.

A regional function sits beside its database. Query time dominates, round trips are nearly free, and a lazy N+1 pattern is a mild embarrassment rather than an outage. Move that same function to the edge and every one of those trips crosses an ocean.

Microsoft publishes median round-trip latency across the Azure backbone, probed continuously and reported at the 50th percentile. Measured from Sydney, the spread is the whole argument.

Nine milliseconds to a neighbouring region. 265 to West Europe. Same code, same query, but three sequential trips now cost 795 milliseconds of pure waiting before the first byte of work happens.

That figure lines up with what Vercel described when it started arguing for pinning functions near their data, a Sydney visitor whose three queries burn over a full second. Cloudflare measures the same effect from the other side, reporting round-trip latency falling from 20 to 30 milliseconds per query down to 1 to 3 once the worker sits beside the database.

So the job becomes minimizing round-trip count, not query cost. That is a different engineering problem, and it is the one that broke edge-rendered apps without anyone getting an error message. The same pressure shows up wherever work gets precomputed ahead of the request, Next.js cache components included.

Cloudflare Walked the Same Road Backward#

If this were a product decision, the rest of the industry would have carried on regardless. Instead Cloudflare, whose entire business is running code in data centres near users, built the feature that moves your code away from them.

Smart Placement watches traffic patterns and relocates a Worker. The docs are blunt about the reason. "If your Worker makes requests to back-end infrastructure such as databases or APIs, it may be more performant to run that Worker closer to your back-end than the end user."

In January 2026 Cloudflare went further with explicit placement hints, letting you pin a Worker near infrastructure in legacy cloud regions to cut latency to existing databases. Two companies with opposing commercial interests, shipping the same instruction.

The detail that settles the question is smaller than either feature. Both companies reach for the same example when they explain the failure, a user in Sydney whose data lives on another continent. Nobody coordinated that, and physics does not need a press release.

The Edge Still Wins Everything That Never Asks a Database#

The strongest objection is that Netlify never got the memo, and it is a fair one. Netlify Edge Functions are current, supported, and still run on Deno at the network location closest to each visitor. The recommended uses are real work, not toys.

• Localizing content for a visitor's region
• Authenticating users before the request reaches an origin
• Personalizing a response
• Redirecting visitors
• Serving relevant ads

Read that list again holding one question. Which of them has to ask a database on another continent anything?

None of them. Every item is request-shaped work, decided from headers, a URL, a cookie and a small pile of config. That is not a counterexample to the argument, it is the argument's boundary, drawn by the people who sell the edge for a living.

Vercel drew the same line and then built for it. Routing Middleware exists as its own primitive so request-time routing stays at the edge, and Edge Config is a global data store whose stated purpose is to let flags, A/B tests, redirects and IP blocking "read data at the edge without querying an external database or hitting upstream servers."

Nobody builds a purpose-made global store for a category of work they are walking away from. The edge kept the half that suits it, and that half got its own database so it would never need the far one.

The rule that falls out is one question rather than a platform preference. If the code needs an origin, run it beside the origin. If it does not, the edge is still the fastest place on the internet to put it, whether that is a single redirect rule or a whole app running on Workers.

What would overturn this. A database that is genuinely everywhere, strongly consistent, with no write penalty, at a price a normal team pays. Round-trip count would stop mattering, the 2022 pitch would come back and be right the second time, and this post would age badly. That database does not exist yet, which is exactly why changing the default was correct.