Cloudflare Workers vs Vercel Functions: 2026 Comparison

Use Cloudflare Workers if you’re building a globally-distributed, I/O-bound API and your costs or p99 latency are becoming a product problem. Use Vercel Functions if you’re deep in Next.js, you need more than 128 MB of memory per function, or your team’s time-to-first-deploy matters more than per-request pricing.

The comparison shifted in June 2025. Vercel deprecated its Edge Functions product — the one built on V8 isolates that most prior benchmarks measured. You’re now choosing between Cloudflare Workers and Vercel Functions with the Node.js runtime running on Vercel’s Fluid Compute layer. If you’ve read comparisons that pit Workers against “Vercel Edge,” you’re reading against a product that no longer exists.

Who this is for

Dev teams already familiar with edge runtimes, making a platform decision for a production deployment in 2026. If you’re still deciding between serverless and containers, start there — this post assumes you’ve already landed on the serverless path.

What changed: Vercel deprecated Edge Functions

In June 2025, Vercel moved Edge Middleware and Edge Functions to run on their Node.js runtime via Fluid Compute, and deprecated the original Edge Functions product. The original product ran in a WinterCG-constrained V8 isolate that blocked most npm packages. Fluid Compute replaced it with full Node.js API coverage, up to 2–4 GB of memory depending on plan, and a different multi-region deployment model.

These are materially different products. Fluid Compute cold-start behavior, memory model, and throughput characteristics are not comparable to the old Edge Functions. Most published third-party benchmarks were run on the deprecated product.

Where I cite pre-June 2025 Vercel numbers below, I note that the product being measured is no longer what you’d deploy to.

What we tested

This article draws from three published benchmarks:

OpenStatus global latency survey, Feb 2024 (Cloudflare Workers) and Mar 2024 (Vercel Edge Functions — the now-deprecated product): end-to-end TTFB from 6 global probe locations. CF report / Vercel report.
Railway server-rendering benchmark, Oct 2025: Next.js, React SSR, and math-intensive workloads across Workers, Vercel, and Railway. Third-party, not a vendor benchmark. Railway blog.
Vercel Fluid Compute benchmark, Oct 2025: Vercel’s own throughput test comparing Fluid Compute to Workers. Resource allocation is not equal — see the CPU section. Vercel blog.

Pricing math uses official figures from Cloudflare’s pricing page and Vercel’s pricing page as of May 2026.

None of these benchmarks are mine. Where a vendor ran its own test, I note that, because vendors optimize for the numbers they publish.

Cold starts and latency

The OpenStatus data from early 2024 shows Workers at P75 138ms, P95 778ms, P99 991ms aggregate TTFB across 6 global probe locations (aggregated across all probes combined). The deprecated Vercel Edge Functions measured P50 106ms, P95 178ms, P99 328ms under the same methodology.

Context matters here. These are TTFB numbers — they include network transit from each probe to the nearest PoP, not cold-start latency alone. The figures conflate geography with runtime performance. Cloudflare runs 330+ PoPs globally; a probe close to a major CF datacenter will see a very different result than one in a secondary region.

More importantly: the Vercel side of this benchmark ran on the deprecated product. The current Fluid Compute product uses bytecode caching and predictive warming to reduce cold starts. Independent third-party TTFB measurements of Fluid Compute at the same scope as OpenStatus’s 6-probe survey are sparse as of mid-2026.

Cloudflare claims sub-5ms cold starts for Workers. This appears in their marketing materials. I could not find a neutral third-party measurement of cold-start-only latency to confirm it — I’m citing it as their stated figure, not a verified benchmark.

Workers P99 latency spikes are the legitimate concern developers raise most often. The cause is isolate eviction under memory pressure and GC pauses — Cloudflare addressed some of this with V8 GC tuning in their October 2025 release, but spiky P99 on Workers remains a real operational characteristic, not FUD.

Practical read: Workers’ P50 TTFB was competitive in that dataset, and 330+ PoPs means most global users hit an edge node nearby. For workloads with tight P99 requirements, audit your specific function against the documented failure modes — file I/O round-trips, cache misses, and Durable Object interactions all compound differently than a simple response.

CPU performance

This is where the comparison gets complicated, because the main benchmark is vendor-run with unequal resources.

Vercel published benchmark results in October 2025 claiming Fluid Compute runs 2–3.5x faster than Workers on Next.js SSR and throughput workloads. The methodology: Vercel Functions allocated 2 vCPUs and 4 GB of RAM; Workers ran on shared CPU with 128 MB of memory. That’s not a controlled comparison — of course a runtime with 4 GB and dedicated vCPUs outperforms one with 128 MB and shared CPU. The speedup is real in that configuration; what it proves about the runtimes is not.

Cloudflare published a response in October 2025. They acknowledged a CPU performance gap on Next.js-specific workloads, attributed part of it to deep integration between Vercel’s Next.js runtime and Fluid Compute, and shipped V8 GC tuning and OpenNext optimizations — claiming approximately 25% improvement on CPU-intensive benchmark workloads generally.

The Railway benchmark from October 2025 — a third party — gives the cleaner signal:

Workload	Fastest platform	Time
React SSR	Cloudflare Workers	163ms
Math-intensive	Cloudflare Workers	550ms
Next.js SSR	Vercel	1089ms

Workers led on generic SSR and compute. Vercel led on Next.js-specific rendering. This pattern makes sense: Fluid Compute has optimizations that are tightly coupled to Next.js’s rendering model. Outside that context, the advantage narrows or reverses.

The constraint underneath the CPU argument is memory. Workers has a hard 128 MB limit on all tiers — free and paid alike. That rules out image processing, large JSON payloads, PDF generation, and anything that needs to buffer significant data in memory. Vercel Functions on Pro allow up to 2–4 GB depending on function configuration. If your function needs more than 128 MB, Workers is not an option, regardless of which runtime is faster.

Pricing

This is the clearest decision factor for teams at meaningful scale.

Monthly requests	Cloudflare Workers (paid)	Vercel Pro
1M	$5	~$20
10M	$5	~$20
100M	$32	~$200+

Source: Cloudflare pricing and Vercel pricing, May 2026. Vercel figures are edge-request estimates; CPU time costs are billed separately.

Cloudflare’s paid plan starts at $5/month and includes 10M requests. Scaling from 10M to 100M adds roughly $27. Vercel Pro is $20/user/month at minimum — that’s the seat cost alone, before any request or compute charges. At 100M requests/month, you’re looking at $200+ on requests alone, with CPU time on top.

Egress is a compounding factor. Cloudflare charges no egress fees from Workers. Vercel charges $0.15/GB after the first 1 TB. For high-bandwidth use cases — streaming large responses, API gateways, or asset serving — this difference adds up fast at scale.

Free tier comparison:

Cloudflare Workers free: 100K requests/day, 10ms CPU limit per request
Vercel Hobby: Serverless Functions included, capped compute hours, no SLA

Teams that are clearly past prototype but not enterprise will find Workers significantly cheaper. The inflection point where Vercel’s DX premium is worth paying for depends on how much of your team’s time it saves — that’s a real factor, but it’s a people-cost calculation, not a per-request one.

If cost at scale is the deciding factor, our Cloudflare vs AWS cost breakdown covers the numbers across Workers, R2, and D1 at 15M, 100M, and 1B requests.

API surface and ecosystem

Cloudflare and Vercel have different ecosystem philosophies, and which one fits you depends on what your application needs at the storage and coordination layer.

Cloudflare Workers comes with a native, integrated set of primitives: KV for key-value storage, D1 for SQLite at the edge, R2 for object storage, Durable Objects for strongly consistent stateful coordination, Queues for async processing, Vectorize for vector search, and Workers AI for model inference. You don’t need a third-party vendor for most of these. The trade-off: these are Cloudflare-specific APIs. If you use Durable Objects extensively and need to migrate off Cloudflare, you’re re-architecting your state layer, not just redeploying your compute.

Durable Objects in particular have no direct Vercel equivalent. They provide strongly consistent, colocated state at the edge — single-instance, actor-model objects that handle WebSocket connections, rate limiting with shared counters, or collaborative editing state. Liveblocks handles up to 500 million messages per day through Workers via Durable Objects. If your use case requires real-time coordination, Workers gives you a native primitive; Vercel would route you to a third-party service like Ably, Upstash, or Partykit.

If you’re also weighing Workers against Lambda — especially for CPU-heavy or long-running functions — our Cloudflare Workers vs AWS Lambda comparison breaks down where each serverless runtime hits its limits.

Node.js compatibility on Workers has improved steadily. The compat flag enables most npm packages as of 2025. Specific gaps — some crypto APIs, certain stream behaviors, native addons — remain. If your code depends on Node.js APIs heavily, test your dependencies before committing to Workers.

Vercel Functions uses third-party integrations for storage: Vercel KV via Upstash, Vercel Postgres via Neon, Vercel Blob for object storage. These are managed proxies to well-regarded vendors. You get battle-tested primitives with familiar APIs, plus vendor support at the storage layer. The downside is an extra dependency and, for functions that hit storage on every request, the latency of a function-to-provider round-trip that may not be colocated at the edge.

Vercel’s strength is its integration with the Next.js and frontend ecosystem. ISR, preview deploys per branch, edge middleware, and image optimization all work together without configuration. The toolchain was designed around this use case.

Developer experience

Vercel wins this category, and it’s not close — unless you’re building APIs rather than full-stack applications.

Zero-config CI/CD, automatic preview deployments per branch, deep ISR integration, and a deployment model that removes entire categories of infrastructure decisions: that’s the Vercel DX story. For a Next.js team, the time from git push to a fully functioning preview URL with production-equivalent behavior is hard to beat. Lee Robinson summarized the workflow in an April 2024 tweet — the point is that the tooling eliminates a class of decisions entirely.

Cloudflare’s DX has improved. Wrangler is a functional CLI, the local dev experience with miniflare is reasonable, and Cloudflare’s docs are thorough. But configuring Workers, KV namespaces, D1 databases, and routing rules is more explicit than Vercel’s convention-based setup. Teams building API backends on Workers report a good experience. Teams migrating a Next.js application to Workers often report friction — OpenNext bridges the gap, but it’s a shim over a platform that wasn’t designed for Next.js, not a native integration.

The indie developer migration pattern is instructive: developers who moved from Vercel to Workers most often cite cost and the Workers ecosystem as the reason, not DX improvement. They’re consciously accepting worse DX in exchange for pricing.

For a deeper look at Vercel’s current value at different team sizes, see our Vercel 2026 review.

Lock-in and portability

Both platforms have lock-in. The mechanism differs.

Cloudflare lock-in concentrates at the storage and coordination layer. Workers themselves are WinterCG-compliant — the compute logic can run on any WinterCG runtime (Deno Deploy, Fastly Compute). Practically, portability of compute without storage is partial. If your application is built on D1 and Durable Objects, migration means re-implementing your data layer.

Vercel lock-in is at the framework integration layer. Features that depend on Vercel’s infrastructure — ISR behavior, edge middleware semantics, image optimization — don’t translate to other hosts without code changes. A migration off Vercel requires auditing which Next.js features you’ve leaned on and which have self-hostable equivalents.

Vercel itself moved its own products off Cloudflare Workers in 2024. The stated reasons: CPU performance on their workloads, spiky latency, and round-trip latency from Vercel’s AWS-hosted services to Cloudflare’s network. This is a useful data point — it’s a real organization with a real production workload making a considered tradeoff, not a synthetic benchmark.

Verdict: Cloudflare Workers vs Vercel Functions

Use Cloudflare Workers if:

Your workload is globally distributed and I/O-bound — API gateway, edge auth, geo-routing, dynamic content at the edge
You need real-time coordination state — WebSockets, collaborative editing, rate limiting with shared counters — and Durable Objects fit the model
You’re running a framework-agnostic stack or an API-only backend, not a Next.js application
Cost and egress fees are a real constraint at your scale
Your functions stay comfortably under 128 MB of memory

Use Vercel Functions if:

You’re running a Next.js application and want the full integrated DX — ISR, preview deploys per branch, edge middleware, and image optimization without configuration
Your functions need more than 128 MB of memory (hard Workers limit, no paid-tier override)
Your team’s deployment workflow and time-to-first-deploy are a higher priority than per-request cost
You want managed storage integrations backed by established third-party vendors

The Vercel “2–3.5x faster” CPU claim requires the asterisk that it was measured with unequal resource allocation (2 vCPU/4 GB vs shared/128 MB) and applies most strongly to Next.js-specific workloads. The third-party Railway benchmark put Workers ahead on generic React SSR and compute-intensive work.

Caveats

The OpenStatus TTFB benchmarks for both platforms are from early 2024. The Vercel side measured the deprecated Edge Functions product, not Fluid Compute. Vercel’s Fluid Compute end-to-end latency has not been independently benchmarked at comparable scope as of mid-2026.

The Railway benchmark predates Cloudflare’s October 2025 GC tuning and OpenNext optimizations. Workers’ CPU performance on common workloads has improved since October 2025; an updated third-party benchmark would be useful.

Neither Cloudflare nor Vercel has an affiliate relationship with toolchew at the time of writing. The researcher brief noted that the affiliate link database was inaccessible; if affiliate links are added before publication, the affiliate frontmatter flag and the standard disclosure block must be updated before the article goes live.