Serverless Platforms Compared: Lambda, Workers, Vercel and Deno

Serverless platforms differ far more than their marketing suggests. The distinctions that decide a project are cold start behaviour, what runtime you get, how long a request may run, and how egress is billed.

Two different execution models

AWS Lambda, Google Cloud Functions and Azure Functions run your code in a container or microVM. You get a full runtime — Node, Python, Go, Java, anything you can package — filesystem access to /tmp, native modules, and long execution limits. The price is cold starts, which range from roughly 100-300 ms for a small Node or Python function to several seconds for a JVM function with a large dependency graph.

Cloudflare Workers and Deno Deploy run V8 isolates instead. There is effectively no cold start because an isolate spins up in single-digit milliseconds, and code runs at an edge location near the user. The price is a restricted runtime: no native Node modules, limited filesystem, and CPU time capped per request rather than wall time. If your function is I/O-bound glue, this is strictly better. If it needs sharp or ffmpeg, it is a non-starter.

Limits that actually bite

• Lambda — 15-minute maximum execution, 10 GB memory ceiling, 6 MB synchronous payload, 250 MB unzipped deployment package (10 GB via container images).
• Cloudflare Workers — CPU time limited per invocation (tens of milliseconds on the free tier, higher on paid), 1 MB script size on the free plan, no long-running compute.
• Vercel Functions — a shorter default execution window than Lambda with a configurable maximum on paid plans; the edge runtime carries the isolate restrictions, the Node runtime does not.
• Deno Deploy — Web-standard APIs, TypeScript natively, no npm packages that require native bindings.

Pricing shapes, not prices

Lambda bills per request plus GB-seconds of memory-time, with a permanent monthly free allowance in the region of a million requests. That is cheap until you add API Gateway, CloudWatch logs and egress, which routinely cost more than the compute. Workers bills per request plus CPU milliseconds, and Cloudflare does not charge egress — for a bandwidth-heavy API that difference can be an order of magnitude on the invoice. Platform-managed offerings like Vercel bundle compute into a plan and then meter overages, which is convenient until a traffic spike. Model your bill on requests and egress before committing.

The database problem

Serverless functions scale horizontally to hundreds of concurrent instances; a Postgres server accepts a fixed connection count, often around 100. Three hundred concurrent Lambdas each opening a connection exhausts the database and takes down everything else using it. The answers are a connection pooler (PgBouncer in transaction mode, RDS Proxy, Supabase's pooler), an HTTP-based database driver, or a data store designed for it. Edge isolates have it worse — the function may run in a datacentre far from your database, so every query pays cross-continent latency. Regional pinning or an edge-native store is the fix.

Picking

• Latency-sensitive API in front of an edge-friendly store: Cloudflare Workers.
• Image processing, PDF generation, anything with native dependencies: Lambda with a container image.
• Next.js or similar, and you want zero infrastructure work: Vercel, with a budget alert set.
• TypeScript-first small services on Web standards: Deno Deploy.
• Steady, predictable traffic around the clock: a small always-on server is usually cheaper and simpler than any of them.