Backend

Netlify ships two serverless runtimes and it's not immediately clear which one to reach for. Standard Functions run Node.js on AWS Lambda with a 10-second timeout. They're full-powered: database drivers, npm packages, heavy computation — everything works. The catch: cold starts. The first invocation after idle time spins up a VM, adds 500ms to 2000ms latency, and users feel it. Edge Functions run Deno at the edge on Netlify's global CDN, no cold starts, but they run for a maximum of 50 milliseconds of CPU time (or 30 seconds wall time). You can't query a Postgres database because the round trip alone eats your CPU budget. At Aidxn, we use a simple rule: edge for fast paths (auth checks, token verification, geo-redirects), standard for slow paths (Stripe webhooks, email sends, database writes). Here's the decision tree, the math, and the pattern for picking the right tool.

The Two Runtimes

Standard Functions are Lambda-backed Node.js. They run anywhere Netlify can boot AWS compute — not always close to the user, but full-featured. They timeout at 10 seconds, which is enough for most backend tasks. Cold starts happen when traffic is sparse: first invocation after 15+ minutes of idle, or during traffic spikes when Lambda scales up new containers. A cold start adds 500–2000ms depending on your function size (larger packages = slower boot).

Edge Functions are Deno-powered and distributed on Netlify's edge servers globally. They start instantly (no cold start penalty), run in the same datacenter as your CDN, and execute with 50ms CPU time budget or 30 seconds wall time (whichever comes first). The CPU budget is tight: a database query takes ~20ms round trip, leaving you 30ms for business logic. The wall time (30s) is relaxed and useful for slow I/O (uploading a file, transcoding), but CPU time is your real constraint. Use cases: token verification (5ms), checking geolocation and redirecting (2ms), OAuth callbacks (10ms), cached data lookups (5ms).

Why Cold Starts Matter — And When They Don't

A Stripe webhook fires, your Standard Function cold-starts for 1500ms, then processes for 500ms. Total latency: 2 seconds. Stripe waits 5 seconds for a 2xx response, so you're fine. But if your product has a "Buy Now" button that calls a Standard Function to process the order and redirect, a cold start means 1.5 seconds of waiting before the user lands on a success page. That feels slow. An Edge Function handles the same flow in 50ms total — starts and finishes before the user's brain registers.

Cold starts are predictable: they happen on the first invocation after idle, or when traffic spikes and Lambda scales. If you're building a B2B SaaS where requests are steady (office hours, regular check-ins), cold starts are rare. If you're building consumer products with bursty traffic (viral tweet, time-limited sale), cold starts multiply.

The simple fix: use Edge Functions for the hot path (user interactions), Standard Functions for background work (Stripe webhooks, email sends). Edge doesn't sleep, so no cold start. Standard Functions sleep between calls; if that's async work, users never notice latency.

Four Use Cases: Edge vs Standard

1. Auth Check (Edge)

User navigates to `/dashboard`. Before rendering, check the JWT in the `Authorization` header. If invalid, redirect to `/login`. Edge Function: verify the token signature (10ms, all CPU), return a redirect or pass-through to the page. No database needed, no external APIs. This is the fastest path: edge wins by 1500ms over standard (cold start penalty). The token signature check is pure crypto — it's built into Deno's runtime.

2. Stripe Webhook (Standard)

Stripe posts `checkout.session.completed`. Your function reads the webhook, verifies the signature (5ms), queries Supabase to check idempotency (20ms), updates the user's subscription (20ms), and returns 200. Total: 50ms. An Edge Function can handle the signature + idempotency lookup (if using a cached KV store), but standard Supabase queries burn CPU time. Standard Function: no CPU time constraint, full Postgres access, logging to Supabase. The 50ms execution is fast enough that a cold start is bearable (background task, not user-facing). Stripe retries for up to 24 hours, so a 2-second total latency on retry is fine.

3. Geo-Redirect (Edge)

User from Australia lands on your marketing site. Redirect to `/au` instead of `/us`. Edge Function: read the `cf-ipcountry` header (auto-injected by Cloudflare), return a rewrite or redirect (2ms). Zero database access, zero external APIs. Edge is the only sensible choice — users see instant region-specific content instead of loading the wrong region and redirecting.

4. Email Send (Standard)

User triggers a "send me a receipt" button. Your function queries the order from Supabase (20ms), builds an email (50ms), calls Resend or SendGrid (500–1000ms), and returns. Total: 1–2 seconds. A cold start adds 500–1500ms. Edge Functions' 50ms CPU budget is laughable here — you'd timeout before querying the database. Standard Function: full 10-second timeout, external API calls, all Node.js packages. This is the bread-and-butter use case.

Cold Start Math: When It Bites

Standard Function cold start adds 500–2000ms depending on bundle size. A minimal function (`return { statusCode: 200 }`) cold-starts in ~500ms. A function with 10 npm packages cold-starts in 1500–2000ms. At Aidxn, we measured a Supabase-enabled function: cold start averaged 1200ms on first invocation. Second+ invocations: 50–100ms. The container stays warm for ~15 minutes, then the VM terminates and the next invocation pays the cold-start tax again.

Cold starts happen in three scenarios: (1) first deployment, (2) idle period after 15+ minutes, (3) traffic spike forcing Lambda to scale. For a SaaS with steady office-hours traffic, cold starts happen once per day at restart. For a consumer product, they happen dozens of times per day. Edge Functions have zero cold start because Deno boots instantly and runs globally on edge servers — no VM spin-up required.

The fix: use Edge for user-facing latency-sensitive paths, Standard for background tasks or async work where the user doesn't wait.

The Decision Tree

Is the user waiting for the response? Yes → Edge Function. No → Standard Function. Does it need database access? Yes → Standard. No → Edge. Does it need external APIs? Simple calls under 20ms → Edge (with caching). Heavy lifting → Standard. Is it geolocation-based? Yes → Edge (built-in headers). Is CPU budget a concern? Yes → Standard (10s timeout, full CPU). Crypto only → Edge (50ms is plenty).

In practice: use Edge for auth checks, token verification, redirects, rate limiting, and simple transforms. Use Standard for database writes, email, webhooks, image processing, and anything calling slow external services. If in doubt, start with Edge and fall back to Standard when you hit the CPU limit.

Six FAQs

Can Edge Functions talk to Supabase?

Yes, but carefully. A Postgres round trip takes ~15–20ms. You have 50ms total CPU. Query the DB, do minimal processing, return. For idempotency checks (single row lookup), it's fine. For complex joins or bulk updates, use Standard. Edge works best with Supabase's REST API (not direct Postgres) because REST is optimized for quick requests. Prefer Netlify KV (edge-local cache) for hot data.

How do I keep a Standard Function warm?

Cron job that calls the function every 5 minutes. Or use Netlify's Scheduled Functions — set a cron expression and Netlify invokes your function on a schedule, keeping the container warm. This is overkill for most apps (cold starts are rare), but useful for mission-critical paths. The real solution: use Edge Functions for user-facing work.

What's "wall time" vs "CPU time" in Edge Functions?

CPU time = active computation (parsing, crypto, logic). Wall time = elapsed time (including I/O, waiting). Edge has 50ms CPU and 30s wall. I/O (database query, API call) burns wall time, not CPU time. So you can do a 5-second API call as long as you use <50ms CPU. Useful for uploading files or calling slow services without logic overhead. CPU time is your real limit.

Can I deploy the same code to Edge and Standard?

No. Edge uses Deno (TypeScript-native, different module system), Standard uses Node.js. They're separate runtimes. Write separate functions, or abstract your business logic into a shared module (not npm packages — edge doesn't use npm). Most teams write handlers separately per runtime and import shared logic from a shared directory.

What happens if my Edge Function exceeds 50ms CPU?

It times out and returns a 504. Netlify logs a timeout error. This is why you test locally and measure CPU time before deploying. Use `deno bench` to profile your functions. If you're close to the limit, consider moving to Standard or removing features.

Is Netlify Edge cheaper than Standard?

Edge Functions are charged per 100K invocations. Standard are charged per GB-second of compute. Edge is cheaper at massive scale if you're doing simple work (no external calls). Standard is cheaper if you're already paying for CPU (long-running handlers). For most teams, the cost difference is negligible — optimize for user experience, not cost.

The Bottom Line

Netlify gives you two tools. Edge Functions are fast (no cold start), run at the edge, and are perfect for auth, redirects, and lightweight checks. Standard Functions are full-powered (all npm packages, 10s timeout), hit by cold-start latency, and are perfect for webhooks, email, and heavy work. The decision is simple: is the user waiting for the response? Use Edge. Is it background work or a slow path? Use Standard. Cold starts matter for consumer products with bursty traffic; steady B2B SaaS rarely sees them. Measure your baseline latency, add a cold-start margin (1–2 seconds), and decide if users will feel it. For Velocity and other Aidxn products, we use Edge for the checkout-redirect path (users see instant success pages) and Standard for webhook processing (Stripe waits, no cold-start penalty). Read more about serverless databases and RLS rules at Stripe Webhooks on Netlify, and see Aidxn Design pricing for serverless-first SaaS architecture consulting.