Search nomadLab

Workers vs Lambda vs Vercel: The Ranking Flips on One Question

Cloudflare bills CPU time, Lambda bills wall-clock, and Vercel splits the difference by pausing CPU billing during I/O while memory keeps running. At 100M requests the cheapest and the most expensive swap places depending on whether your function waits or computes.

Updated

Comparisons of these three usually open with cold starts and end with a table of benchmark numbers somebody else measured. Skip both. The thing that decides your bill is duller and easier to check: each platform meters a different quantity, and one of them is the quantity your function spends most of its time not doing.

AWS Lambda bills GB-seconds of wall-clock time. If your handler awaits a database for 180 milliseconds, you pay for 180 milliseconds. Cloudflare Workers bills CPU time and nothing else, so that same wait is free. Vercel’s fluid compute splits the difference, and its docs are refreshingly blunt about it: “If the request is waiting on I/O, CPU billing pauses but memory billing continues.” Rates below came off the vendor pricing pages and the AWS price list on 23 August 2026.

The same one hundred million requests a month, priced two ways. For an I/O-bound function with 200 milliseconds wall-clock and 20 milliseconds of CPU, Cloudflare Workers costs 71 dollars, Vercel 190 dollars, and AWS Lambda on Arm 287 dollars. For a CPU-bound function where all 200 milliseconds are CPU, Lambda on Arm stays at 287 dollars, Workers rises to 431 dollars, and Vercel rises to 830 dollars. Lambda is the only one whose price does not change, because it bills wall-clock time either way. 100M requests a month, 200ms each. Only the work inside changes. Waiting on I/O: 20ms of CPU inside 200ms Cloudflare Workers$71 Vercel fluid compute$190 AWS Lambda, Arm$287 Computing: all 200ms is CPU AWS Lambda, Arm$287, unchanged Cloudflare Workers$431 Vercel fluid compute$830 Lambda does not move because it never asked what you were doing. It billed the clock.
Cheapest to most expensive, then most expensive to cheapest. Vercel's memory line and Lambda's requests are included; Vercel's $20 per seat is not.

Three rate cards, three units

Charged for timeCharged for memoryCharged per request
Cloudflare WorkersCPU only, $0.02 per million CPU-msNothing. 128 MB, fixed$0.30 per million over 10M, $5 base
AWS LambdaWall-clock, $0.0000166667 per GB-second on x86Folded into the GB-second$0.20 per million
Vercel fluid computeCPU only, $0.128 per CPU-hour in iad1Wall-clock, $0.0106 per GB-hour$0.60 per million on Pro

Workers has no memory meter at all, because there is no memory dial: every isolate gets 128 MB and that is the whole offer. Lambda has no separate CPU meter, because CPU is allocated in proportion to memory and both are inside the GB-second. Vercel is the only one that meters the two independently, which is why it is the only one where the CPU and memory lines can move in opposite directions.

Two other Workers limits follow from the same design. The paid CPU cap is five minutes, with a 30 second default you raise in config, and there is no enforced wall-clock limit at all while the client stays connected. A Worker can sit waiting on a slow upstream for as long as the client tolerates it and the meter does not run.

The two workloads, in full

Both cases are 100 million requests a month at 200ms wall-clock, 1 GB of memory where memory is configurable.

Waiting on I/O (20ms of CPU inside each 200ms):

CalculationMonthly
Workers$5 base + 90M requests × $0.30/M + 1,970M CPU-ms × $0.02/M$71
Vercel, iad1555 CPU-hours × $0.128 + 5,555 GB-hours × $0.0106 + 100M × $0.60/M$190
Lambda, Arm20M GB-seconds × $0.0000133334 + 100M × $0.20/M$287
Lambda, x86Same shape at $0.0000166667$353

Computing (all 200ms is CPU):

Monthly
Lambda, Arm$287
Lambda, x86$353
Workers$431
Vercel, iad1$830

Workers goes from four times cheaper than Lambda to fifty percent more expensive. Vercel goes from second place to nearly three times Lambda. Lambda does not move by a cent, and that is the whole point: it is the only one of the three that never asked what your function was doing.

Most HTTP handlers are the first case. They parse a request, await a query or two, shape some JSON and return. The CPU-bound case is image processing, PDF generation, crypto, compression, parsing very large payloads, or any model inference. If you cannot say which shape yours is, the answer is in your existing traces, and it is a cheaper question to answer than a migration.

The line that is not on any of the three rate cards

Egress. From us-east-1, AWS charges $0.09 per GB for the first 10 TB out to the internet, then $0.085, $0.07, and $0.05 as volume climbs. An API returning 10 KB responses at 100 million requests a month moves about 954 GB, which is roughly $86 a month on top of everything above. Cloudflare charges nothing for egress, and never has.

For the I/O-bound case, that single line is larger than the entire Workers bill.

What Workers still cannot do

The 128 MB per isolate is the hard edge, and no plan raises it. There is no filesystem, no native binaries, no spawning processes. Database access is HTTP-shaped, so a Postgres instance inside a VPC is not reachable the way it is from Lambda.

Language support has moved, though, and the older comparisons have not caught up. Python Workers are in open beta behind the python_workers compatibility flag, with FastAPI, Pydantic and Langchain among the supported packages. That is not the same as Lambda’s fully supported Python, and beta is doing real work in that sentence, but “Workers is JavaScript only” is no longer accurate.

Lambda’s side of the trade is a full Linux environment, up to 10 GB of memory, 15 minutes per invocation, container images, layers, VPC networking, and every runtime you want. You pay for that flexibility on every millisecond you spend waiting for a database inside it.

What this does not decide

Two things sit outside the arithmetic.

The first is where the code runs. Workers executes at whichever Cloudflare location is nearest the user; a Lambda in us-east-1 answers from us-east-1 unless you replicate it yourself. For a globally distributed audience the network latency difference dwarfs any of the numbers above, and it does not appear on the bill.

The second is what happens when the workload stops being spiky. Both Workers and Lambda charge only while work is in progress, which is exactly the deal you want for bursty traffic and exactly the wrong deal for something that runs flat out. The point where a serverless meter loses to a rented container is a duty cycle question, and I worked it out with the same rate cards in Lambda vs containers.

The useful move this week is not a migration. It is opening your traces, taking the median CPU time and the median wall-clock time for your busiest handler, and putting them into the three formulas above. If those two numbers are close together, the platform you are on probably matters less than the region you are in. If they are far apart, you have been paying one of these platforms for waiting.

Keep reading