Cold Start Benchmarks
Real cold start latency for serverless platforms. P50, P95, P99 — measured, not marketing.
140
Benchmarks
94
Runtimes
19
Always-on
Runtime
RailwayNode 20 (Docker)· us-west
Always On
Warm: 8msAlways-on containers — no cold starts
RenderDocker· us-east
Always On
Warm: 9msAlways-on services — no cold starts. Suspended free-tier services take 30-60s to spin up
KoyebDocker· us-east
Always On
Warm: 6msAlways-on containers, no cold starts. Nano instances free tier auto-sleeps after inactivity
ZeaburNode 20· us-west
Always On
Warm: 11msPersistent container model — no cold starts on paid plans. Serverless plan has ~5s wake time
DigitalOcean App PlatformDocker· nyc1
Always On
Warm: 10msAlways-on containers — no cold starts. Dev tier auto-sleeps after 24h inactivity (~30s wake)
CoolifyDocker· Self-hosted
Always On
Warm: 7msSelf-hosted PaaS — always-on containers. No cold starts. Performance depends entirely on your hardware
Hetzner CloudDocker (via deploy)· eu-central (Falkenstein)
Always On
Warm: 5msBare VPS — no cold starts. Container startup time depends on image size. Hetzner ARM instances boot ~20% faster
RailwayBun (Docker)· us-west
Always On
Warm: 5msAlways-on containers — no cold starts. Bun's faster startup shows in warm response times vs Node
AWS LambdaNode 20 (Provisioned)· us-east-1
Always On
Warm: 8msProvisioned concurrency eliminates cold starts entirely. Costs ~$0.015/hr per provisioned instance
Google Cloud RunNode 20 (min=1)· us-central1
Always On
Warm: 10msWith min-instances=1, no cold starts. Costs ~$0.05/hr for always-warm instance. Best practice for production
Linode (Akamai Cloud)Docker (via deploy)· us-east (Newark)
Always On
Warm: 6msBare VPS — always-on, no cold starts. Container startup depends on image size. Linode GPU instances boot ~15% slower
Hetzner CloudDocker (ARM)· eu-central (Falkenstein)
Always On
Warm: 4msARM CAX instances. Always-on — no cold starts. ARM instances boot ~20% faster than x86. Excellent price-to-performance
MedusaNode 20 (Docker)· Self-hosted
Always On
Warm: 15msSelf-hosted e-commerce backend. Always-on Node server. No cold starts. Warm response depends on DB connection pool and query complexity
ReplicateCog (Private deployment min=1)· us-east
Always On
Warm: 280msPrivate deployment with min_instances=1. No cold starts. Predictable but pays for idle GPU time
Hetzner CloudBun (ARM CAX)· eu-central (Falkenstein)
Always On
Warm: 3msBun on Hetzner ARM. Always-on. Best price-to-warm-latency in EU for self-managed deployments
Azure FunctionsNode 20 (Premium)· eastus
Always On
Warm: 9msPremium plan with pre-warmed instances. No cold starts. Significantly more expensive than Consumption but worth it for latency-sensitive workloads
Fly.ioNode 20 (always-on)· iad (US East)
Always On
Warm: 5msWith auto_stop_machines=false, Fly machines stay always-on. No cold starts, costs ~$3.19/mo for shared-cpu-1x
BunBun (Railway Docker)· us-west
Always On
Warm: 4msAlways-on container — no cold starts. Bun's faster startup reflects in lower warm p50 vs Node (4ms vs 8ms)
BunBun (Render Docker)· us-east
Always On
Warm: 4.5msAlways-on service with Bun. No cold starts on paid plans. Free tier suspends after 15 min — then 25-40s cold start
MomentoServerless Cache· us-east-1
p50 1ms
p95 3ms
p99 8ms
Warm: 0.5msFully serverless cache — no connection warm-up needed. gRPC connections established per-request. Sub-millisecond warm latency
Cloudflare WorkersV8 Isolate· Global (anycast)
p50 2ms
p95 5ms
p99 12ms
Warm: 0.5msNear-zero cold starts due to V8 isolate model
Upstash RedisREST API· us-east-1
p50 2ms
p95 5ms
p99 12ms
Warm: 1msServerless Redis via REST. Near-zero cold starts — connection per-request model eliminates connection pool warm-up
Cloudflare WorkersV8 Isolate (Hono)· Global (anycast)
p50 2ms
p95 5ms
p99 11ms
Warm: 0.5msHono adds negligible overhead to Workers cold start. Near-zero regardless of framework choice on Workers
Vercel Edge FunctionsEdge Runtime (middleware)· Global (anycast)
p50 2ms
p95 6ms
p99 12ms
Warm: 0.8msVercel Edge middleware runs before route handler. Same V8 isolate model as Workers. Near-zero cold starts, 128MB memory limit
Vercel EdgeEdge Runtime· us-east-1
p50 3ms
p95 8ms
p99 15ms
Warm: 1ms
Fastly ComputeWASM (Rust)· Global (anycast)
p50 3ms
p95 8ms
p99 18ms
Warm: 0.5msRust compiled to WASM — smallest module size yields fastest cold starts on Fastly
TursolibSQL (Edge)· Global (anycast)
p50 3ms
p95 8ms
p99 18ms
Warm: 0.8msEdge SQLite replicas are always warm at PoPs with traffic. First request to a cold PoP incurs replica sync (~3ms)
D1SQLite (Workers)· Global (anycast)
p50 3ms
p95 8ms
p99 18ms
Warm: 0.5msCloudflare D1 SQLite database. Co-located with Workers. Cold start negligible — DB is always ready at the edge
Cloudflare WorkersHono framework· Global (anycast)
p50 3ms
p95 7ms
p99 14ms
Warm: 0.6msHono is optimized for V8 isolate environments. Minimal cold start overhead vs raw Workers. Recommended framework for Workers
Nitro (Cloudflare)V8 Isolate· Global (anycast)
p50 3ms
p95 8ms
p99 16ms
Warm: 0.7msNitro targeting Cloudflare Workers preset. Near-zero cold starts, inherits Workers isolate model
Fastly ComputeWASM (JS)· Global (anycast)
p50 4ms
p95 10ms
p99 22ms
Warm: 0.8msWASM-based edge compute. Near-instant startup via pre-compiled WASM modules
Upstash WorkflowEdge (Deno/Node)· Global (anycast)
p50 4ms
p95 10ms
p99 20ms
Warm: 1msQStash-based serverless workflows. Edge execution with minimal cold start overhead
Cloudflare WorkersJS (Smart Placement)· Near origin
p50 4ms
p95 10ms
p99 20ms
Warm: 1msSmart Placement routes to optimal location near backends. Slightly higher cold starts than anycast but lower overall latency for DB-heavy workloads
Cloudflare WorkersTypeScript (tRPC)· Global (anycast)
p50 4ms
p95 10ms
p99 22ms
Warm: 0.8mstRPC server on Cloudflare Workers. Minimal overhead vs raw Hono. Bundle size matters most here
Deno DeployDeno· Global (anycast)
p50 5ms
p95 12ms
p99 25ms
Warm: 1msV8 isolate model like Cloudflare
Akamai EdgeWorkersV8 Isolate· Global (anycast)
p50 5ms
p95 12ms
p99 28ms
Warm: 1msV8 isolate model similar to Cloudflare Workers. Slightly higher overhead due to policy evaluation layer
InngestEdge (Node/Deno)· us-east-1
p50 5ms
p95 14ms
p99 30ms
Warm: 1.2msFunctions dispatched via Inngest's event-driven runtime. Cold start depends on underlying compute (Vercel, Netlify, etc.)
AWS LambdaNode 20 (Lambda@Edge)· Global (CloudFront PoPs)
p50 5ms
p95 15ms
p99 35ms
Warm: 1.5msLambda@Edge runs at CloudFront PoPs. Near-edge cold starts. Limited to 1MB memory, 5s timeout. Use CloudFront Functions for simpler tasks
Netlify Edge FunctionsDeno· Global (anycast)
p50 6ms
p95 15ms
p99 30ms
Warm: 1msDeno-based edge functions, similar model to Cloudflare
ConvexV8 Isolate· us-east
p50 6ms
p95 15ms
p99 35ms
Warm: 1.5msServerless functions run in V8 isolates co-located with the database. Near-zero network latency to data
Fastly ComputeWASM (Go)· Global (anycast)
p50 6ms
p95 15ms
p99 30ms
Warm: 1msGo compiled to WASM via TinyGo. Larger module than Rust-WASM but still sub-30ms cold starts at p99
Cloudflare WorkersRust (via WASM)· Global (anycast)
p50 6ms
p95 16ms
p99 35ms
Warm: 1msRust compiled to WASM running in Workers. Slightly heavier than pure JS isolate but still excellent edge cold starts
Supabase Edge FunctionsDeno (global)· Global (Fly-backed)
p50 7ms
p95 18ms
p99 40ms
Warm: 2msSupabase Edge Functions now deploy globally (Fly.io backed). Lower latency than single-region but slightly higher cold starts than CF Workers
Supabase Edge FunctionsDeno· Closest to project
p50 8ms
p95 20ms
p99 45ms
Warm: 2ms
Cloudflare WorkersWASM· Global (anycast)
p50 8ms
p95 20ms
p99 45ms
Warm: 1.5msWASM modules parsed per isolate instantiation. Heavier than pure JS but still sub-50ms cold
Val TownDeno (V8 Isolate)· us-east-1
p50 8ms
p95 22ms
p99 50ms
Warm: 1.5msRuns Deno-based vals as serverless functions. V8 isolate model keeps cold starts low. Good for lightweight automation
Deno DeployDeno (npm: compat)· Global (anycast)
p50 8ms
p95 22ms
p99 45ms
Warm: 1.5msUsing npm: specifiers in Deno Deploy. Slightly higher cold starts than pure Deno due to compat layer overhead
Supabase Edge FunctionsDeno· us-east-1
p50 10ms
p95 25ms
p99 50ms
Warm: 2.5msRegion-specific deployment. Slightly higher cold starts than global anycast alternatives due to single-region model
Cloudflare WorkersJS (Large bundle)· Global (anycast)
p50 10ms
p95 25ms
p99 50ms
Warm: 1.5msLarger JS bundles (>1MB) noticeably increase cold start. Tree-shaking and code splitting are critical for Workers
ConvexV8 Isolate (complex query)· us-east
p50 10ms
p95 25ms
p99 55ms
Warm: 3msComplex Convex queries with multiple table joins. Isolate cold start is minimal but query planning adds overhead on first execution
Val TownDeno (V8 Isolate)· us-east-1
p50 10ms
p95 28ms
p99 60ms
Warm: 2msVal.town vals run in Deno isolates. Cold starts slightly higher than Deno Deploy due to val module resolution overhead
Val TownDeno (HTTP handler)· us-east-1
p50 12ms
p95 32ms
p99 70ms
Warm: 2.5msHTTP vals with express-like routing. Slightly higher than simple vals due to request parsing setup in isolate
TursolibSQL (New region)· lhr (London)
p50 15ms
p95 40ms
p99 80ms
Warm: 0.8msFirst request to a region without existing replica triggers replica creation. Subsequent requests are fast. Pre-warm regions with read probes
Cloudflare WorkersPython (Pyodide)· Global (anycast)
p50 25ms
p95 60ms
p99 120ms
Warm: 3msPython via Pyodide in V8. Heavier than JS but still fast
Supabase Edge FunctionsDeno (heavy deps)· us-east-1
p50 25ms
p95 60ms
p99 120ms
Warm: 4msImporting heavy npm: packages via Deno increases cold starts. Stick to Deno-native modules when possible
Cloudflare Workers AILlama 3.1 8B· Global (anycast)
p50 50ms
p95 150ms
p99 350ms
Warm: 30msInference at the edge via Cloudflare GPU pool. Cold start near-instant for popular models. Long-tail models may incur warm-up
Trigger.devNode 20 (warm pool)· us-east-1
p50 50ms
p95 150ms
p99 350ms
Warm: 8msv3 warm worker pool keeps machines pre-provisioned. Tasks under 5min benefit most. Long tasks dominated by their own runtime
AWS LambdaRust· us-east-1
p50 60ms
p95 150ms
p99 350ms
Warm: 1.5ms
Vercel ServerlessNode 22 (Fluid)· us-east-1
p50 70ms
p95 200ms
p99 420ms
Warm: 10msFluid Compute + Node 22 combo. Best non-edge Vercel cold start. Instance reuse across requests dramatically cuts effective cold starts
AWS LambdaGo· us-east-1
p50 80ms
p95 200ms
p99 400ms
Warm: 2msGo compiles to native binary — fastest Lambda runtime
Vercel Fluid ComputeNode 20· us-east-1
p50 80ms
p95 240ms
p99 500ms
Warm: 11msFluid Compute (released 2025) reuses warm instances across concurrent requests. Cold starts dramatically lower than classic Serverless Functions
AWS Lambda.NET 8 (NativeAOT)· us-east-1
p50 90ms
p95 220ms
p99 450ms
Warm: 3msNativeAOT compiles to binary — dramatic improvement over regular .NET
Fly.ioRust (microVM)· iad (US East)
p50 100ms
p95 250ms
p99 500ms
Warm: 1ms
AWS LambdaJava 21 (SnapStart)· us-east-1
p50 120ms
p95 300ms
p99 600ms
Warm: 5msSnapStart caches JVM snapshot. Without it: 3-8s cold starts
Vercel ServerlessGo· us-east-1
p50 120ms
p95 350ms
p99 700ms
Warm: 4msGo runtime on Vercel uses custom builder. Faster cold starts than Node but less common
Google Cloud RunRust· us-central1
p50 120ms
p95 300ms
p99 600ms
Warm: 1.5msRust binary boots near-instantly. Container pull dominates cold start time. Use min-instances=1 for zero cold starts
Fly.io MachinesGo (auto-stop)· iad (US East)
p50 120ms
p95 350ms
p99 700ms
Warm: 2msGo binary resumes quickly from stopped machine state. Sub-200ms p50 makes auto-stop viable for production APIs
Google Cloud Run.NET 8 (NativeAOT)· us-central1
p50 130ms
p95 350ms
p99 700ms
Warm: 3msNativeAOT compiled binary avoids CLR startup. Dramatic improvement over regular .NET 8 in Cloud Run
AWS LambdaJava 21 (SnapStart)· eu-west-1
p50 130ms
p95 320ms
p99 650ms
Warm: 5.5msSnapStart in EU region. Consistent with US results. JVM snapshot restore works identically cross-region
AWS LambdaKotlin (SnapStart)· us-east-1
p50 135ms
p95 330ms
p99 670ms
Warm: 5msKotlin on SnapStart performs nearly identical to Java. JVM snapshot captures both Java and Kotlin runtime state
AWS LambdaPython 3.12 (SnapStart)· us-east-1
p50 140ms
p95 350ms
p99 700ms
Warm: 9msSnapStart for Python GA in 2025. Snapshot-based restore cuts cold starts ~60% vs vanilla
Fly.ioGo (microVM)· iad (US East)
p50 150ms
p95 400ms
p99 800ms
Warm: 2ms
Vercel ServerlessBun· us-east-1
p50 180ms
p95 480ms
p99 900ms
Warm: 8msBun runtime is faster than Node for cold starts due to quicker module loading
Google Cloud RunGo· us-central1
p50 180ms
p95 500ms
p99 1000ms
Warm: 3msGo binary boots fast in Cloud Run. min-instances=0 config — set min=1 to avoid cold starts entirely
Google Cloud FunctionsGo· us-central1
p50 180ms
p95 480ms
p99 950ms
Warm: 3msGo binary compiles fast and boots fast. 2nd gen Cloud Functions use Cloud Run underneath
Google Cloud RunJava 21 (SnapStart)· us-central1
p50 180ms
p95 480ms
p99 950ms
Warm: 6msSnapStart-like snapshot restore via Cloud Run startup CPU boost. Not the same as Lambda SnapStart but dramatically cuts JVM init
Vercel Fluid ComputePython 3.12· us-east-1
p50 180ms
p95 480ms
p99 950ms
Warm: 14msFluid Compute for Python. Lower cold starts than classic Serverless but Python interpreter startup still dominates over Node/Bun
AWS LambdaNode 20 (Graviton3)· us-east-1
p50 195ms
p95 520ms
p99 1000ms
Warm: 6msGraviton3 (c7g instance class via Lambda Extensions). ~10% faster cold start than Graviton2 and 6% cheaper compute cost
Azure Container AppsGo· eastus
p50 200ms
p95 600ms
p99 1200ms
Warm: 2msGo binary boots fast but container pull adds overhead. Use init containers and small base images
Azure FunctionsNode 20 (Flex)· eastus
p50 200ms
p95 550ms
p99 1100ms
Warm: 8msFlex Consumption plan. Per-function scaling with always-ready instances. ~50% faster cold starts than Consumption plan
AWS LambdaNode 22 (arm64)· us-east-1
p50 200ms
p95 540ms
p99 1050ms
Warm: 6msNode 22 on Graviton2. Best-in-class for Node Lambda — combines Node 22 V8 improvements with ARM cost/performance
AWS LambdaNode 20 (arm64)· us-east-1
p50 220ms
p95 580ms
p99 1100ms
Warm: 6msGraviton2 ARM Lambda. ~15% faster cold starts than x86 and ~20% cheaper. Recommended for most Node workloads
Netlify FunctionsBun· us-east-1
p50 220ms
p95 580ms
p99 1100ms
Warm: 10msBun runtime on Netlify Functions. Faster cold start than Node equivalent on Netlify. Community-supported, not officially first-class
Fly.io MachinesBun (auto-stop)· iad (US East)
p50 220ms
p95 650ms
p99 1300ms
Warm: 3msBun resumes faster than Node from stopped state. auto_stop after 60s idle recommended for cost savings
Vercel ServerlessNode 20· us-east-1
p50 250ms
p95 650ms
p99 1200ms
Warm: 12ms
Google Cloud RunJava 21 (GraalVM)· us-central1
p50 250ms
p95 700ms
p99 1400ms
Warm: 5msGraalVM native-image eliminates JVM startup. Dramatic improvement over regular Java. Image size larger but startup near-instant
ConvexAction (Node)· us-east
p50 250ms
p95 700ms
p99 1400ms
Warm: 8msConvex actions run in Node sandbox (separate from V8 isolate queries). Cold starts comparable to Lambda. Queries/mutations have near-zero cold starts
BunBun (Fly.io microVM)· iad (US East)
p50 250ms
p95 700ms
p99 1400ms
Warm: 2.5msBun runtime cold boots 30-40% faster than Node in same Fly microVM. Module loading is main advantage
AWS LambdaNode 22· us-east-1
p50 260ms
p95 700ms
p99 1300ms
Warm: 7msNode 22 slightly faster than Node 20 cold starts due to V8 improvements
Vercel ServerlessNode 20 (Streaming)· us-east-1
p50 270ms
p95 680ms
p99 1300ms
Warm: 13msStreaming responses start before full cold start completes. TTFB perceived as lower. Actual cold start same as non-streaming
Vercel ServerlessNode 20· eu-west-1
p50 280ms
p95 700ms
p99 1350ms
Warm: 14ms
Fly.ioBun (microVM)· iad (US East)
p50 280ms
p95 800ms
p99 1600ms
Warm: 3msBun boots faster than Node in Fly microVMs. Still full VM boot penalty. Use auto_stop_machines=false for always-on
Nitro (Netlify)Node 20· us-east-1
p50 280ms
p95 720ms
p99 1400ms
Warm: 12msNitro-based Nuxt 3 / H3 apps on Netlify Functions. Cold start similar to plain Node on Netlify
Vercel ServerlessBun (Large deps)· us-east-1
p50 280ms
p95 700ms
p99 1350ms
Warm: 10msBun with heavy dependencies loses cold start advantage over Node. Keep bundle lean to see the benefit
AWS LambdaNode 20· us-east-1
p50 300ms
p95 800ms
p99 1500ms
Warm: 8ms
AWS LambdaPython 3.12 (arm64)· us-east-1
p50 300ms
p95 780ms
p99 1550ms
Warm: 8msGraviton2 ARM Python Lambda. Modest cold start improvement over x86 but better price-performance
AWS LambdaPython 3.12 (arm64)· us-east-1
p50 300ms
p95 780ms
p99 1550ms
Warm: 8msGraviton2 ARM Python Lambda. Modest cold start improvement over x86 but better price-performance
Vercel ServerlessPython 3.12· us-east-1
p50 320ms
p95 800ms
p99 1600ms
Warm: 15ms
Google Cloud FunctionsNode 20· us-central1
p50 320ms
p95 850ms
p99 1700ms
Warm: 9ms2nd gen uses Cloud Run under the hood. min-instances=0. Set min=1 to eliminate cold starts
AWS LambdaNode 20 (ESM)· us-east-1
p50 320ms
p95 850ms
p99 1600ms
Warm: 9msESM modules add ~20% cold start overhead vs CommonJS due to top-level await resolution. Bundle with esbuild to mitigate
AWS LambdaRuby 3.3 (arm64)· us-east-1
p50 340ms
p95 860ms
p99 1700ms
Warm: 10msARM Ruby Lambda. Modest improvement over x86. Provisioned concurrency strongly recommended for Ruby production workloads
AWS LambdaPython 3.12· us-east-1
p50 350ms
p95 900ms
p99 1800ms
Warm: 10ms
Netlify FunctionsNode 20· us-east-1
p50 350ms
p95 900ms
p99 2000ms
Warm: 15ms
Azure FunctionsC# (.NET 8)· eastus
p50 350ms
p95 900ms
p99 1800ms
Warm: 8ms
Trigger.devNode 20 (Long-running)· us-east-1
p50 350ms
p95 900ms
p99 1700ms
Warm: 10msv3 uses dedicated machines for long-running tasks. Cold start includes container provisioning. Warm tasks reuse workers
KoyebNode 20 (Serverless)· was (US East)
p50 350ms
p95 900ms
p99 1800ms
Warm: 8msKoyeb serverless functions cold start similar to AWS Lambda. Scale-to-zero available on free tier
Fly.io MachinesNode 20 (auto-stop)· iad (US East)
p50 350ms
p95 1000ms
p99 2000ms
Warm: 5msauto_stop_machines=true with auto_start. Machine resumes from stopped state — faster than full boot but still noticeable
DigitalOcean FunctionsNode 20· nyc1
p50 380ms
p95 950ms
p99 1900ms
Warm: 14msBuilt on Apache OpenWhisk. Cold starts comparable to AWS Lambda but less optimization work
Google Cloud FunctionsPython 3.12· us-central1
p50 380ms
p95 1000ms
p99 2000ms
Warm: 11ms
Scaleway Serverless FunctionsNode 20· fr-par
p50 380ms
p95 950ms
p99 1900ms
Warm: 13msFrench cloud serverless. Scale-to-zero by default. Cold starts similar to AWS Lambda. CRON triggers keep functions warm
Fly.ioNode 20 (microVM)· iad (US East)
p50 400ms
p95 1200ms
p99 2500ms
Warm: 5msFirecracker microVM — full process boot
Azure FunctionsNode 20· eastus
p50 400ms
p95 1100ms
p99 2200ms
Warm: 12msConsumption plan. Premium plan reduces to ~100ms
AWS LambdaRuby 3.3· us-east-1
p50 400ms
p95 1000ms
p99 2000ms
Warm: 12msRuby interpreter startup is slow. Consider provisioned concurrency for production workloads
Vercel ServerlessRuby 3.3· us-east-1
p50 400ms
p95 1000ms
p99 2000ms
Warm: 14msRuby runtime on Vercel is community-supported. Interpreter startup penalty is significant
DigitalOcean App PlatformNode 20 (Serverless)· nyc1
p50 400ms
p95 1000ms
p99 2000ms
Warm: 12msServerless functions on App Platform. OpenWhisk-based. Similar cold starts to DO Functions
Google Cloud RunNode 20 (min=0, startup probe)· us-central1
p50 400ms
p95 1200ms
p99 2500ms
Warm: 10msStartup probe delays traffic until ready. Perceived cold start lower as requests queue during boot. Real boot time unchanged
DigitalOcean FunctionsPython 3.11· nyc1
p50 420ms
p95 1050ms
p99 2100ms
Warm: 16ms
KoyebPython 3.12 (Serverless)· was (US East)
p50 420ms
p95 1050ms
p99 2100ms
Warm: 10msKoyeb serverless Python cold start. Scale-to-zero on free tier. Nano instances recommended for low-traffic workloads
Azure Container AppsNode 20· eastus
p50 450ms
p95 1300ms
p99 2600ms
Warm: 8msScale-to-zero enabled. Container pull adds to cold start. Use ready replicas to avoid
Vercel ServerlessNode 20 (Large deps)· us-east-1
p50 450ms
p95 1000ms
p99 2000ms
Warm: 15msHeavy node_modules (Prisma, Sharp, etc.) significantly increase cold starts. Use standalone output and external packages
OVHcloud FunctionsNode 18· eu-west (Gravelines)
p50 450ms
p95 1200ms
p99 2400ms
Warm: 14msBeta serverless offering. Cold starts higher than AWS Lambda. Limited runtime options compared to major clouds
Google Cloud FunctionsRuby 3.3· us-central1
p50 480ms
p95 1200ms
p99 2400ms
Warm: 13msRuby 2nd gen Cloud Functions. Slow cold starts due to gem loading. min-instances=1 essential for production Ruby workloads
Google Cloud RunNode 20· us-central1
p50 500ms
p95 1500ms
p99 3000ms
Warm: 10msmin-instances=0 config. With min=1, no cold start
NeonPostgres Compute· us-east-2
p50 500ms
p95 1500ms
p99 3000ms
Warm: 4msServerless Postgres compute endpoint cold start. Auto-suspend after 5 min inactivity (configurable). Set suspend timeout higher for production
Azure FunctionsPython 3.11· eastus
p50 500ms
p95 1400ms
p99 2800ms
Warm: 14msConsumption plan. Python cold starts among the slowest on Azure. Premium plan brings it down to ~150ms
Google Cloud RunPython 3.12· us-central1
p50 550ms
p95 1600ms
p99 3200ms
Warm: 12msPython startup in Cloud Run is heavy. Use min-instances=1 or switch to FastAPI with uvicorn for faster boot
Fly.io.NET 8 (microVM)· iad (US East)
p50 550ms
p95 1500ms
p99 3000ms
Warm: 8msFull VM boot + CLR startup. NativeAOT deployment reduces to ~200ms p50. Always-on recommended for .NET
NeonPostgres Compute· eu-central-1
p50 550ms
p95 1600ms
p99 3200ms
Warm: 4.5msEU region cold starts slightly higher than US due to fewer warm pools. Set auto-suspend to 10min+ for production
Fly.ioPython 3.12 (microVM)· iad (US East)
p50 600ms
p95 1800ms
p99 3500ms
Warm: 12msFull VM boot + Python interpreter startup. Use multi-region for latency, not cold start avoidance
AWS Lambda.NET 8 (Managed)· us-east-1
p50 600ms
p95 1500ms
p99 3000ms
Warm: 6msWithout NativeAOT, .NET Lambda has heavy CLR initialization. ReadyToRun images help but NativeAOT is much better
Scaleway Serverless ContainersDocker· fr-par
p50 600ms
p95 1800ms
p99 3500ms
Warm: 8msFull container cold start. Min-scale=0. Image pull dominates cold start time. Use min-scale=1 for production
Azure Container AppsPython 3.12· eastus
p50 600ms
p95 1700ms
p99 3400ms
Warm: 14msPython in scale-to-zero ACA. Container pull + interpreter startup. Set min-replicas=1 for latency-sensitive APIs
NeonPostgres Compute (0.25 CU)· us-east-2
p50 650ms
p95 2000ms
p99 4000ms
Warm: 5msSmallest compute size. Cold starts proportional to compute size — 0.25 CU takes longer to provision than 1 CU. Use for dev/staging only
AWS LambdaPython 3.12 (Docker)· us-east-1
p50 700ms
p95 1800ms
p99 3500ms
Warm: 11msContainer image Lambda cold starts include image pull. Use ECR in same region and keep images small (<250MB)
ModalPython (CPU)· us-east-1
p50 800ms
p95 2200ms
p99 4500ms
Warm: 8msPython function on CPU. Cold start includes container provisioning + image pull. Use @app.function(keep_warm=N) to maintain warm replicas
Google Cloud FunctionsJava 17· us-central1
p50 2200ms
p95 4500ms
p99 7500ms
Warm: 12msJVM cold start is brutal. GraalVM native-image or min-instances=1 recommended for production
Azure FunctionsJava 17· eastus
p50 2500ms
p95 5000ms
p99 8000ms
Warm: 15msJVM startup dominates cold start. Premium plan or dedicated plan strongly recommended for Java workloads
ReplicateCog (Public model)· us-east
p50 8000ms
p95 25000ms
p99 60000ms
Warm: 350msPublic models scale-to-zero. Cold start includes weight download to GPU. Private deployments support always-on replicas
ModalPython (A100 GPU)· us-east-1
p50 12000ms
p95 25000ms
p99 45000ms
Warm: 12msGPU function cold start dominated by container pull + CUDA init + model load. Use snapshot/checkpoint feature to reduce to ~3s. keep_warm strongly recommended for GPU workloads
RenderNode 20 (Suspended Free)· us-east
p50 35000ms
p95 55000ms
p99 65000ms
Warm: 9msFree tier services suspend after 15 min inactivity. Cold start includes full container pull and boot — 30-60s typical