Node and Edge Runtimes
AdvancedEdge starts instantly and runs close to the user, with a restricted API surface and no TCP. Node has everything and a cold start. Most routes should stay on Node.
Overview
Next can run a route in one of two runtimes, and the choice is narrower than the marketing suggests. The edge runtime is a Web-APIs-only environment distributed globally: fast to start, close to the user, and unable to open a database connection or use most Node built-ins. Node is the full platform with a cold start. The honest default is Node for everything except middleware, with edge reserved for the specific cases where geography dominates and the work is trivial — because a route on the edge that then calls a database in Mumbai has moved the latency, not removed it.
The Difference
What each has, and what edge gives up.
export const runtime = 'nodejs' // the default
export const runtime = 'edge'
// EDGE
// + near-zero cold start
// + runs in a location near the user
// + cheaper per invocation
// - Web APIs only: no fs, no net, no most Node built-ins
// - no TCP, so no Postgres/MySQL client — HTTP-based drivers only
// - no native modules (bcrypt, sharp, canvas)
// - a bundle size limit, typically a few MB
// - shorter execution limits
// NODE
// + everything: any npm package, any database driver
// + longer execution, larger bundles
// - cold starts
// - runs in one region
// The trap: an edge function near the user that queries a database
// in one region pays the distance on every query. Being close to the
// user only helps if the work is self-contained — a redirect, a
// header, a cached lookup, a token check.
// Middleware is always edge, which is why it cannot read a session
// from the database.Choosing
A short list, because the default is right most of the time.
// Edge is a good fit for:
// middleware (no choice)
// geolocation and A/B routing
// a token check with no database read
// streaming a proxied AI response
// simple, globally-hit redirects
// Node for:
// anything touching Postgres, Prisma or a TCP driver
// image or file processing
// long-running work
// anything using a Node-only library
// in practice: nearly every page and most handlers
// If you want edge with a database, the driver must speak HTTP:
import { neon } from '@neondatabase/serverless' // Neon over HTTP
import { createClient } from '@supabase/supabase-js' // PostgREST
// A normal pg client will not work, and the error is obscure.
// Measure before switching. Edge saves tens of milliseconds of cold
// start; a badly-placed database call costs hundreds.Cold Starts
What actually makes a serverless route slow to wake.
// A cold start is the platform booting a container, loading your
// bundle and running module-level code. It happens after idle, after
// a deploy, and when scaling out.
// What makes it worse — all within your control:
// a large bundle for that route (imports pull in dependencies)
// heavy module-level work (a client constructed at import time)
// many separate database connections per instance
// Reduce it:
// import lazily inside the handler, not at module scope, for
// anything only some paths need
const { PDFDocument } = await import('pdf-lib')
// reuse a single client across invocations
let cached: PrismaClient | undefined
export const db = cached ?? (cached = new PrismaClient())
// use a connection pooler — serverless opens far more connections
// than a long-lived server, and Postgres runs out
// (PgBouncer, Neon's pooled endpoint, Prisma Accelerate)
// Two platforms compound: a cold Vercel function calling a cold Fly
// machine means the first visitor waits for both. min_machines_running
// = 1 on the backend removes half of it.
// And remember the whole point of static: a prerendered page has no
// cold start at all, because no function runs.Key Points to Remember
- 1The edge runtime is Web APIs only — no TCP, so no conventional database driver, and no native modules
- 2Being near the user only helps if the work is self-contained; an edge route querying a distant database moves latency rather than removing it
- 3Middleware always runs on edge, which is why it cannot read a session from a database
- 4Node is the right default for pages and most handlers; edge suits redirects, token checks and proxied streams
- 5Reduce cold starts with lazy imports and a reused client, and use a connection pooler because serverless opens many connections
Interview Questions
Sign in to ask AriaWhat can the edge runtime not do, and why?
Why might moving a route to the edge make it slower?
Why do serverless deployments need a database connection pooler?
Ask Aria about Node and Edge Runtimes
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.