Cloudflare Workers vs Vercel Edge vs Lambda 2026

Three platforms, three radically different architectures for running server-side code in 2026. Cloudflare Workers runs V8 isolates in 300+ locations with zero cold starts. Vercel Edge Functions run the same isolate model but are tightly integrated with Next.js deployments. AWS Lambda runs your code in Firecracker microVMs — more powerful, but with cold starts and container overhead. The right choice depends on your latency requirements, runtime constraints, and existing infrastructure.

TL;DR

Cloudflare Workers is the default choice for new edge compute projects — zero cold starts, 300+ global PoPs, an exceptional developer experience, and a full platform ecosystem (KV, D1, R2, Durable Objects, Queues). Vercel Edge Functions are the right choice when you're already on Vercel and need low-latency middleware, A/B testing, or auth checks for Next.js routes — they're Workers under the hood with tighter framework integration. AWS Lambda is the choice when you need full Node.js runtime capabilities (native modules, long execution, heavy compute), deep AWS ecosystem integration, or you're operating at extreme scale with enterprise requirements.

Key Takeaways

Cloudflare Workers: Zero cold starts (<5ms), 300+ PoPs, 10ms CPU limit (free) / up to 5 min (paid), 128 MB memory, $5/mo + $0.30/million requests
Vercel Edge Functions: Zero cold starts (<5ms), Vercel edge network, 50ms CPU per execution unit / 5 min wall-clock, primarily recommended for Next.js middleware in 2026
AWS Lambda: 1.2–2.8s cold starts (Node.js 20 p95); SnapStart reduces JVM to ~200ms; ARM64 45-65% faster; INIT phase now billed since August 2025
Runtime difference: Workers/Edge = Web APIs only (no fs, no native modules); Lambda = full Node.js runtime
Workers free tier: 100K requests/day — generous for development and low-traffic production
Lambda free tier: 1M requests/month + 400K GB-seconds compute time

At a Glance

	Cloudflare Workers	Vercel Edge Functions	AWS Lambda
Architecture	V8 isolates	V8 isolates (Workers-based)	Firecracker microVMs
Cold start	Zero (<5ms)	Zero (<5ms)	1.2–2.8s p95 (Node.js 20)
Global PoPs	300+	Vercel edge network	~30+ regions
CPU limit	10ms (free) / up to 5 min (paid)	50ms/unit, 5 min wall-clock	15 minutes
Memory	128 MB	128 MB	Up to 10 GB
Runtime	Web APIs (Service Worker API)	Web APIs (Edge Runtime)	Full Node.js / Python / etc.
`fs` module	❌	❌	✅
Native npm modules	❌	❌	✅
Deployment size	1 MB (free) / 10 MB (paid)	4 MB	50 MB (zip) / 250 MB (unzipped)
Free tier	100K req/day	Vercel Hobby plan	1M req/month
Paid pricing	$5/mo + $0.30/M req	Included in Vercel Pro ($20/mo)	$0.20/M req + compute
Platform ecosystem	KV, D1, R2, Durable Objects, Queues	Vercel KV, Blob, Postgres	All AWS services
Open-source runtime	Workerd	Vercel Edge Runtime	Firecracker (open source)

Cloudflare Workers

Workers is the most mature edge compute platform. The V8 isolate model — where a single V8 instance handles thousands of concurrent requests without container spin-up overhead — delivers genuine zero cold starts at any scale.

The V8 Isolate Advantage

Traditional serverless (Lambda, Cloud Functions) uses containers or VMs. Cold starts happen when no warm container is available — the platform must boot the VM, initialize the runtime, and load your code. V8 isolates skip all of this. They're lightweight JavaScript execution contexts that share a running V8 engine. Spinning up a new isolate costs microseconds, not hundreds of milliseconds.

// Cloudflare Worker — runs in every PoP globally
export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const url = new URL(request.url)

    // Geolocation data available in every request — free
    const country = request.cf?.country ?? 'US'
    const city = request.cf?.city ?? 'Unknown'

    // KV — low-latency key-value from the edge
    const cached = await env.CACHE.get(url.pathname)
    if (cached) {
      return new Response(cached, {
        headers: { 'X-Cache': 'HIT', 'Content-Type': 'application/json' }
      })
    }

    // D1 — SQLite database at the edge
    const result = await env.DB.prepare(
      'SELECT * FROM products WHERE slug = ?'
    ).bind(url.pathname.slice(1)).first()

    const response = JSON.stringify(result)
    ctx.waitUntil(env.CACHE.put(url.pathname, response, { expirationTtl: 300 }))

    return new Response(response, {
      headers: { 'Content-Type': 'application/json' }
    })
  }
}

What Workers Can't Do

The Web API-only runtime is the primary constraint:

No native Node.js modules — bcrypt, sharp, canvas, puppeteer (native bindings) won't run
CPU time limit — 10ms on free, up to 5 minutes on paid. Not suitable for video processing, ML inference, or heavy compute
No file system access — fs module is unavailable (use R2 for file storage)
WebSocket connections — Durable Objects required for stateful WebSocket handling

The Workers Ecosystem

Workers' edge-native platform primitives are its real moat:

KV — eventually consistent key-value store, reads from local PoP
D1 — distributed SQLite, edge-readable with replication
R2 — S3-compatible object storage with zero egress fees
Durable Objects — stateful objects with strong consistency, single-threaded actor model
Queues — message queue for async job processing
AI Gateway — proxy for AI API calls with caching and rate limiting

Pricing:

Free: 100K requests/day, 10ms CPU/request
Workers Paid: $5/month, 10M requests + 30M CPU-ms included, +$0.30/million requests, +$0.02/million CPU-ms after

Vercel Edge Functions

Vercel Edge Functions are Cloudflare Workers under a different name — Vercel actually runs them on the Cloudflare network. What differentiates them is the integration with Next.js and the Vercel deployment pipeline.

The Next.js Integration

Edge Functions shine for Next.js middleware — the code that runs before every request hits your routes:

// middleware.ts — runs at the edge before every request
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl

  // A/B testing — cookie-based variant assignment
  const variant = request.cookies.get('ab-variant')?.value
  if (!variant) {
    const response = NextResponse.next()
    const newVariant = Math.random() > 0.5 ? 'a' : 'b'
    response.cookies.set('ab-variant', newVariant)
    return response
  }

  // Auth redirect
  const session = request.cookies.get('session')?.value
  if (pathname.startsWith('/dashboard') && !session) {
    return NextResponse.redirect(new URL('/login', request.url))
  }

  // Geo-based routing
  const country = request.geo?.country ?? 'US'
  if (country !== 'US' && pathname === '/') {
    return NextResponse.rewrite(new URL(`/${country.toLowerCase()}`, request.url))
  }

  return NextResponse.next()
}

export const config = {
  matcher: ['/((?!_next/static|favicon.ico).*)'],
}

Edge Route Handlers

You can also deploy route handlers to the edge runtime:

// app/api/geo/route.ts
export const runtime = 'edge' // Use edge instead of Node.js runtime

export async function GET(request: Request) {
  // Edge-specific APIs available via NextRequest
  return Response.json({
    message: 'Running at the edge',
    region: process.env.VERCEL_REGION,
  })
}

Vercel Edge Limitations

Same runtime constraints as Workers (no native modules, no fs)
Tied to Vercel — not portable; deploying the same middleware to another platform requires changes
Vercel is retreating from edge-by-default — Vercel's own VP of Product moved their services back to Node.js serverless functions in 2025. Edge is now recommended primarily for middleware; Node.js Serverless Functions remain the workhorse for route handlers
50ms CPU hard limit per execution unit — complex processing hits this quickly
No direct equivalents of Durable Objects or R2 — use Vercel KV (Upstash-backed) and Vercel Blob (Cloudflare R2-backed)

AWS Lambda

Lambda predates the edge compute wave by nearly a decade and remains the dominant serverless platform by usage volume. It's not an edge runtime — Lambda functions run in specific AWS regions — but it compensates with raw capability that V8 isolate runtimes can't match.

Full Runtime Capabilities

// Lambda — full Node.js runtime
import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3'
import sharp from 'sharp' // ← Native module: works in Lambda, fails in Workers
import { createCanvas } from 'canvas' // ← Native bindings: Lambda only
import fs from 'fs'

const s3 = new S3Client({ region: 'us-east-1' })

export const handler = async (event) => {
  // Download image from S3 (large file operations: fine in Lambda)
  const object = await s3.send(new GetObjectCommand({
    Bucket: 'my-bucket',
    Key: event.imageKey,
  }))

  const imageBuffer = Buffer.from(await object.Body.transformToByteArray())

  // Resize with sharp — native bindings, not possible in Workers
  const resized = await sharp(imageBuffer)
    .resize(800, 600, { fit: 'cover' })
    .webp({ quality: 80 })
    .toBuffer()

  return {
    statusCode: 200,
    headers: { 'Content-Type': 'image/webp' },
    body: resized.toString('base64'),
    isBase64Encoded: true,
  }
}

Cold Starts: The Lambda Trade-Off

Lambda's primary weakness is cold starts — the latency when no warm execution environment is available. For Node.js 20, cold starts are 1.2–2.8s (p95). Python 3.12 is 2.1–3.5s. Java without SnapStart is 4–7s. AWS SnapStart (Java, .NET) reduces this to ~200ms via pre-initialized memory snapshots.

August 2025 billing change: AWS began charging for the INIT phase (cold start initialization time) at the same rate as execution time. This raised cold-start-inclusive costs by ~22x for cold-start-heavy workloads — from ~$0.80 to ~$17.80 per million cold-start invocations. Provisioned Concurrency or ARM64 is now even more important for cost management.

Mitigation strategies:

Provisioned Concurrency — keep N Lambda instances warm at all times (billed at $0.0000041667/GB-second even when idle)
ARM64 (Graviton2) — 45–65% faster cold starts than x86 across all runtimes, and ~20% cheaper per GB-second
SnapStart — Java and .NET runtimes, snapshot-based initialization (~200ms cold start)
Minimize package size — smaller deployment packages initialize faster; tree-shake aggressively

# serverless.yml — Lambda with provisioned concurrency
functions:
  api:
    handler: src/handler.main
    runtime: nodejs20.x
    architecture: arm64  # 20% cheaper, same or better performance
    provisionedConcurrency: 5  # Keep 5 warm instances
    memorySize: 512
    timeout: 30

AWS Ecosystem Integration

Lambda's advantage is the AWS surface area. Direct integrations with:

API Gateway — full HTTP layer, request/response transformation
EventBridge — event-driven triggers from any AWS service
SQS/SNS — queue-triggered processing
RDS Proxy — connection pooling for relational databases
VPC — run Lambda inside your private network with database access

Pricing:

Free tier: 1M requests/month + 400K GB-seconds
After free tier: $0.20/million requests + $0.0000166667/GB-second (x86), ~20% cheaper on ARM64
INIT phase (cold start): billed at same rate as execution since August 2025
Provisioned Concurrency: $0.0000041667/GB-second (billed continuously — e.g., 10 × 512 MB instances ≈ $15/month)
Example: 512 MB Lambda warm 100ms = $0.0000083334/invocation; cold start adds 1-3s of INIT billing on top

Decision Guide

Use Cloudflare Workers When:

You need zero cold starts at truly global scale
Your workload is edge-native (geolocation, header manipulation, A/B testing)
You want the full Workers platform (KV + D1 + R2 + Durable Objects)
You're building APIs that don't need native Node.js modules
You want to co-locate logic and data (Workers + D1 at the same edge node)

Use Vercel Edge Functions When:

You're already on Vercel deploying Next.js applications
You need Next.js middleware for auth, redirects, A/B testing, or geo-routing
You want edge performance without managing Workers directly
Your edge logic can share Next.js types and utilities

Use AWS Lambda When:

You need native Node.js modules (sharp, bcrypt, puppeteer, ML libraries)
Your functions run for more than 30 seconds (Lambda allows up to 15 minutes)
You need more than 128 MB memory (Lambda goes up to 10 GB)
You're deep in the AWS ecosystem (RDS, SQS, EventBridge, VPC)
You're processing heavy workloads: video transcoding, image processing, ML inference
You need enterprise compliance, VPC isolation, or AWS-specific security controls

Real-World Latency (2026 Benchmarks)

Scenario	Cloudflare Workers	Vercel Edge	AWS Lambda (warm)	AWS Lambda (cold, Node.js 20)
p50 global	10–30ms	20–50ms	50–150ms (regional)	1,200–2,800ms
p95 global	~40ms	~80ms	~216ms (Lambda@Edge)	2,800ms+
Cold start	<5ms	<5ms	~200ms (SnapStart/Java)	1.2–7s by runtime
Warm execution overhead	~1ms	~1ms	~120ms (Node p95)	—

Source: Cloudflare internal benchmarks + community measurements.

The Hybrid Pattern

Most production architectures in 2026 use both:

CDN → Cloudflare Workers (routing, auth, caching, geo)
      ↓
      Vercel/Next.js (SSR, ISR, PPR for full pages)
      ↓
      AWS Lambda (heavy compute: image processing, PDF generation, ML)

Edge handles fast, simple request manipulation. Lambda handles slow, powerful computation. You don't have to choose just one.

Compare edge runtime npm package adoption on PkgPulse.