If you're deciding whether to move auth middleware or routing to Cloudflare Workers, profile before you port. Pull your ten slowest endpoints by p95 latency and check whether the time goes to distance from the user or to something else, such as a database query or a payment provider. Edge compute only fixes the first kind.
The vendor documentation has moved since most comparison posts were written, which is why this one sticks to published limits and prices. It covers where Workers and Vercel's Edge runtime differ, what belongs at the edge in a B2B SaaS, and where Durable Objects and Smart Placement help or bite.
Cloudflare Workers vs Vercel Edge Functions: which should a SaaS pick?
Pick Cloudflare Workers when you want an edge-first platform with published limits and stateful primitives, because Vercel's own docs now recommend moving from its Edge runtime to Node.js. That recommendation is the most useful fact in this comparison. Vercel's Edge Runtime page, last updated 3 August 2026, opens with a note recommending a move from edge to Node.js for improved performance and reliability, and says both runtimes run on Fluid compute with Active CPU pricing. It adds that starting in Next.js 16.3, setting runtime = 'edge' is no longer supported and routes run on Node.js.
Older posts that say "just use Vercel Edge" predate that note. Here's how the two compare on what each vendor publishes (checked 30 September 2026):
| Cloudflare Workers | Vercel Edge runtime | |
|---|---|---|
| Vendor direction | Primary platform | Docs recommend migrating to Node.js |
| Code size | 64 MiB uncompressed on both plans | 1 MB Hobby, 2 MB Pro, 4 MB Enterprise, after gzip |
| Time limits | 10 ms CPU per request on Free; 30 s default, up to 5 min on Paid | Must begin responding within 25 s, can stream up to 300 s |
| Pricing model | Free plan, or Paid from $5 a month | Fluid compute with Active CPU pricing |
| Node.js APIs | Check the compatibility docs for your dependencies | Subset only: no filesystem, no eval, no direct require |
The Workers limits page lists 100,000 requests a day on the free plan with no daily cap on paid, 128 MB of memory per isolate, and 50 subrequests per invocation on Free versus 10,000 on Paid. The pricing page lists a $5 monthly minimum on Paid with 10 million requests and 30 million CPU milliseconds included, then $0.30 per additional million requests and $0.02 per additional million CPU milliseconds, and no charge for egress.
Use this order of questions to decide, as a recommendation. First, if you're on Next.js on Vercel and only need middleware, follow Vercel's note and stay on Node.js. Second, if you need coordinated state or logic that should run in front of any framework, look at Workers. Third, check that your dependencies don't rely on Node.js APIs the target runtime lacks, because the Vercel page lists what its Edge runtime doesn't support.
The free plan's 100,000 requests a day works out to about 69 requests a minute averaged over 24 hours. That's plenty for a prototype's auth and routing layer, and a poor fit for anything with bursty traffic, so check your peak, not your average, before you stay on Free.
CPU time is the number that decides whether Workers can hold business logic or only routing. Ten milliseconds per request on Free covers a token check and a redirect. It won't cover much more, so plan for Paid if your logic does real work.
What should you move to the edge?
Move stateless, latency-sensitive decisions to the edge and leave stateful business logic on your origin. This is a recommendation based on how the limits above behave, not a vendor rule. For most B2B products the shortlist is short:
- Authentication token verification and session checks, which are read-only and block every request anyway.
- Request routing and A/B bucket assignment, since neither needs a database round trip.
- Rate limiting and abuse filtering, so bad traffic is rejected before it reaches your origin.
- Geo-based redirects and localized asset rewriting.
- API gateway concerns such as header injection, request shaping and light caching.
Billing state, multi-tenant queries and anything that touches a real transaction belong on the origin, where debugging doesn't mean chasing a request across many edge computing locations. Consider a hypothetical request path: a Worker verifies the token, applies a rate limit, adds a header and forwards the request to your origin, which handles everything else. The edge layer stays small enough to reason about during an incident, and the origin keeps its single source of truth. A JWT signature check is a good edge citizen because it needs a public key and a clock. A Stripe webhook handler that writes to three tables is not.
Are cold starts a problem on Workers?
Not for most SaaS traffic, according to Cloudflare's own engineering write-up. In a July 2020 blog post, Cloudflare says its isolate technology warms a Worker in under 5 milliseconds and that it hints the runtime to load the Worker as soon as the TLS ClientHello arrives, so the Worker is ready before the request does. Treat that as a 2020 statement of the design, since I haven't found a current figure to cite. The Workers limits page separately caps startup time at one second. If your Worker does heavy work at import time, that's where you'll feel it. You can also measure this yourself: deploy a trivial Worker beside your real one and compare time to first byte for both from a distant location.
Are Durable Objects a good fit for multi-tenant SaaS state?
Durable Objects fit well when a tenant, room or document needs one authoritative place for coordinated state, and they need careful scoping because each object is single-threaded. Cloudflare's Durable Objects docs describe a special kind of Worker that combines compute with storage, gives each object a globally unique name you can address from anywhere, and provides durable, transactional, strongly consistent storage of up to 10 GB per object.
The docs list coordinating multiple clients, real-time communication over WebSockets, batch processing and aggregation, and queues and workflows as use cases. For a SaaS, my reading is that per-tenant counters, collaborative documents and rate-limit state are the natural candidates.
The same page says Durable Objects are single-threaded and cooperatively multi-tasked, like code in a browser. My inference from that: work for one object queues behind other work for that object, so a single hot key becomes your throughput ceiling. That page doesn't publish a per-object request rate, so load-test your worst case before you rely on it.
The design choice follows. Consider a hypothetical multi-tenant product where one enterprise customer drives far more traffic than the rest. One object per tenant puts all of that customer's writes through one instance. One object per resource inside the tenant, such as per document or per room, spreads the load. That's the boundary question you'd face at any serverless layer: whatever you pick inherits that layer's concurrency model.
How does Smart Placement help chatty Workers?
Smart Placement moves a Worker's execution closer to the backend it calls most, which helps when a Worker makes several round trips to a single-region origin. The Smart Placement docs say it analyzes your Worker's traffic patterns and, for each candidate location, weighs the Worker's performance against the network latency added by forwarding the request, moving execution only if a location is significantly faster.
Enabling it is one setting in your Wrangler config:
{
"placement": { "mode": "smart" }
}
The docs list three limits. It only affects fetch event handlers, not RPC methods or named entrypoints. It only considers locations where the Worker has previously run, so it can't place your Worker in a location that doesn't normally receive traffic. Static assets are always served from the location nearest the request. It can also take up to 15 minutes to analyze a Worker after deployment, so don't judge it on the first request after a deploy.
When is edge logic a distraction instead of an upgrade?
Edge logic is a distraction when your bottleneck sits in a database query, a payment provider or an origin service and not in the distance between the user and your server. The fix for those is somewhere less exciting than a second deployment target.
Consider a hypothetical booking product where the slow moment is the payment-confirmation screen. Shaving milliseconds off the marketing page changes nothing about that wait. The BookBed case study describes a Flutter, Firebase and Stripe stack and doesn't mention any edge deployment. I'd read that as a reminder that having users in many places doesn't automatically mean you need compute in many places.
Before you write any Workers code, check where your p95 comes from. If the honest answer is a query plan or a webhook chain, moving routing to the edge adds a second thing to keep in sync during every incident. Workers earns a place in your SaaS MVP stack once you've confirmed the bottleneck is distance. If you do go ahead, move one route first behind a feature flag and compare p95 before and after, so the decision rests on your own numbers and not on a benchmark from someone else's stack.
Take your ten slowest endpoints this week and ask of each one: would it still be slow if it ran instantly at zero distance from every user? Which of them answer yes?