Vercel Functions are the on-demand compute layer behind almost everything dynamic you deploy on Vercel: API routes, server-rendered pages, form handlers, webhooks, and AI orchestration. For years the platform split that compute into two products with separate mental models, Edge Functions and Serverless Functions. As of 2026 that split has mostly collapsed. Both now run as Vercel Functions on a single execution model called Fluid compute, and the real decision is no longer which product to use. It is which runtime to attach to each function: the Edge runtime or the Node.js runtime. This post covers how each runtime behaves, what Fluid compute changed, how cold starts actually play out, and a clear rule for picking one.
If the platform itself is new to you, our introduction to Vercel covers where Functions sit in the wider product.
One platform, two runtimes
The most important thing to understand in 2026 is structural. In June 2025, Vercel deprecated the standalone Edge Functions product and folded its capabilities into Vercel Functions. Edge Middleware became Vercel Routing Middleware, and both middleware and functions now run on Vercel Functions, per Vercel’s changelog. The Edge runtime did not disappear. It became one of several runtimes you select per function.
That consolidation matters because it removed the old billing and region divide. Vercel now describes Fluid compute as running the same regions on the same pricing model regardless of runtime, so choosing Edge over Node is no longer a choice about which pricing table applies. You pick a runtime per function, and the cost model underneath behaves the same way.
Fluid compute supports five runtimes: Node.js, Python, the Edge runtime, Bun, and Rust, according to the Fluid compute documentation. For the classic edge-versus-serverless question, the two that matter are the Edge runtime and Node.js.
How the Edge runtime works
The Edge runtime is a lightweight JavaScript environment built on V8 isolates, the same engine that powers Chrome. It does not boot a full container or microVM per request. An isolate is a slimmer unit of isolation, so a cold instance can wake in roughly a millisecond rather than the hundreds of milliseconds a container needs. If you have read our explainer on what containers are, the mental model is the opposite: no OS image to spin up, just a fresh V8 context.
That speed comes with hard constraints. The Edge runtime exposes Web Standard APIs, not the full Node.js standard library. You cannot use fs, native addons, or some Node crypto methods, and a number of database drivers that assume a Node socket layer will not run there. It also has its own duration rule. A function on the Edge runtime must begin sending a response within 25 seconds, after which it can continue streaming for up to 300 seconds, per Vercel’s Functions limits documentation.
The upside is proximity. Edge functions execute close to the requesting user across Vercel’s global network rather than in one home region, which is why they suit latency-sensitive logic that runs on every request. If you want the background on why running compute near the user reduces round trips, our piece on what a CDN is covers the same distribution principle.
How the Node.js runtime works
The Node.js runtime is what most people mean by "serverless" on Vercel. It runs the full Node.js API surface, so your existing packages, database clients, ORMs, and native dependencies work without modification. Historically each invocation ran in its own microVM, which gave strong isolation at the cost of slower starts and idle waste. Fluid compute changed that execution model, which we cover in the next section.
The Node.js runtime carries the heavier limits you would expect for real backend work. On the current limits table, functions default to 2 GB of memory and 1 vCPU, with Pro and Enterprise teams able to scale a single function to 4 GB and 2 vCPU. Bundles can be up to 250 MB uncompressed, and the Large Functions beta lifts that to 5 GB for workloads that ship model files or large binaries. Duration defaults to 300 seconds and can extend to an 800-second maximum on paid plans, with a 1800-second (30 minute) extended maximum in beta for supported Node.js and Python versions. Requests and responses are capped at a 4.5 MB body. These figures all come from Vercel’s Functions limits documentation.
By default a Node.js function runs in a single region (iad1 unless you change it). Pro teams can pin up to three regions and Enterprise teams can run in all of them, but this is opt-in placement rather than the automatic global spread the Edge runtime gives you.
Fluid compute changed the tradeoff
For years the honest answer to "edge or serverless" was a set of tradeoffs around cold starts and idle cost. Fluid compute reworked enough of that to change the default advice. Vercel enabled it by default for new projects on April 23, 2025, per the Fluid compute documentation, and it applies to the Node.js and Python runtimes.
Three of its behaviors matter for this decision:
- Optimized concurrency: instead of one microVM per request, multiple invocations can share a single warm instance. Vercel positions this as especially useful for I/O-bound work like calling AI models or querying a vector database, where a function spends most of its time waiting rather than computing.
- Active CPU pricing: you pay for active CPU time plus provisioned memory time, and time spent waiting on I/O (an AI model, a database query) does not count as active CPU. For AI orchestration that idles on network calls, that is a material cost change.
- Background processing: with
waitUntil, a function can return a response to the user and keep running work like logging or analytics afterward.
The practical effect is that the Node.js runtime lost much of its old penalty. A workload that once felt too cold-start-heavy or too expensive to sit idle on serverless is now a reasonable fit on Fluid compute. This is the same infrastructure shift we touched on in the coverage of Vercel Sandbox persistence: Vercel is steadily giving serverless the ergonomics of a long-lived server.
Cold starts, honestly
Cold starts are where the two runtimes still diverge. The Edge runtime’s isolate model means there is almost no cold start to speak of, because there is no container image to load. The Node.js runtime has to initialize a heavier environment, so its cold path is longer.
Fluid compute narrows the gap rather than closing it. On Node.js version 20 and later, Vercel caches compiled bytecode after the first execution so subsequent cold starts skip recompilation, and it pre-warms functions on production deployments, per the Fluid compute documentation. Both reduce the pain of an infrequently called Node function.
For a rough sense of scale, one independent latency comparison from monitoring vendor OpenStatus measured Edge functions around a 106ms median globally against Node serverless functions near 246ms when warm and closer to 859ms on a cold start (OpenStatus benchmark). Treat those as directional, not a guarantee for your workload, but the shape is consistent with the architecture: isolates win on the cold path and on global reach, while a warm Node function is competitive for everything else.
Runtimes, limits, and what actually constrains you
The limits are usually what force the decision. Here is the shape of it for the two runtimes, drawn from Vercel’s current documentation.
| Property | Edge runtime | Node.js runtime (Fluid) |
|---|---|---|
| Location | Global, near the user | Single region by default (multi-region on paid plans) |
| Cold start | Near zero (V8 isolate) | Reduced via bytecode caching and pre-warming |
| APIs | Web Standard APIs only | Full Node.js standard library |
| Duration | Respond within 25s, stream up to 300s | 300s default, up to 800s (1800s beta) |
| Bundle size | Small, code-only | 250 MB, up to 5 GB with Large Functions |
| Best for | Lightweight per-request logic | Database, heavy compute, AI orchestration |
Two shared limits catch people regardless of runtime: the 4.5 MB request and response body cap, and a pool of 1,024 file descriptors shared across concurrent executions, which the runtime itself partly consumes. If you are opening many database or socket connections without pooling, the descriptor ceiling is a real constraint.
Choosing a Vercel Functions runtime
Because both runtimes now share pricing and regions, the choice comes down to what the function needs, not what it costs. A workable default rule:
- Reach for the Edge runtime when the logic is small, runs on every request, and benefits from being close to the user: authentication and token checks, A/B test assignment, geolocation-based redirects, feature flags, and lightweight personalization in middleware.
- Reach for the Node.js runtime when the function talks to a database, uses a package or native module that expects Node, ships large dependencies, runs longer than a few seconds, or orchestrates AI calls. Fluid compute makes this the safe default for most backend work.
When you are unsure, default to Node.js. Vercel itself now recommends the Node.js runtime with Fluid compute for new projects, reserving the Edge runtime for cases where global proximity on lightweight logic is the specific win. The old reflex of pushing everything to the edge for speed no longer holds, because a warm Fluid function covers most of that ground without the API constraints. AI-heavy applications in particular, like the ones you would build with the Vercel AI SDK, lean toward Node.js precisely because their cost is I/O wait that Fluid compute does not bill as active CPU.
Frequently Asked Questions
Are Vercel Edge Functions deprecated?
The standalone Edge Functions product was deprecated in June 2025, but the Edge runtime was not. Its capabilities moved into Vercel Functions, where the Edge runtime is now one of several runtimes you can select per function. Edge Middleware similarly became Vercel Routing Middleware. Existing edge code keeps working; it just runs under the unified Vercel Functions umbrella now.
What is Fluid compute in one sentence?
Fluid compute is Vercel’s default execution model that lets multiple requests share a warm function instance, bills active CPU time rather than idle wait, and reduces cold starts. It applies to the Node.js and Python runtimes and has been on by default for new projects since April 2025.
Which runtime is cheaper, Edge or Node.js?
Neither is inherently cheaper. Since the 2025 consolidation, both runtimes share the same pricing model based on active CPU time and provisioned memory time. Cost depends on how your function behaves, not which runtime label it carries. An I/O-bound function that waits on external calls is cheap on either because waiting is not billed as active CPU.
Can I use my usual npm packages on the Edge runtime?
Only if they rely on Web Standard APIs. The Edge runtime does not provide the full Node.js standard library, so packages that use fs, native addons, some Node crypto methods, or socket-based database drivers will not run there. If a package assumes Node, use the Node.js runtime instead.
How long can a Vercel Function run?
On the Node.js and Python runtimes, the default is 300 seconds, with an 800-second maximum on Pro and Enterprise plans and a 1800-second extended maximum in beta. The Edge runtime must begin sending a response within 25 seconds and can then stream for up to 300 seconds. For work that needs to run for minutes to months, Vercel points to its Workflows product instead.
Do cold starts still matter with Fluid compute?
Less than they used to. The Edge runtime has almost no cold start because V8 isolates wake in about a millisecond. The Node.js runtime still has a cold path, but Fluid compute shortens it with bytecode caching on Node 20 and later and by pre-warming production functions. For most warm traffic the difference is small; for rarely called functions the edge still starts faster.
Should I put everything on the edge for speed?
No. That was common advice before Fluid compute, but a warm Node.js function is now competitive for most work and avoids the edge runtime’s API limits. Use the edge for small, per-request logic that benefits from running near the user, and use Node.js for anything that touches a database, ships heavy dependencies, or orchestrates AI calls.
