Home/Learn/Next.js/Node and Edge Runtimes

Node and Edge Runtimes

Advanced
Production

Edge 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.

Web APIs only, and no TCP
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.

Node by default; edge for self-contained work
// 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.

Lazy imports, a reused client, a connection pooler
// 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 Aria
1

What can the edge runtime not do, and why?

Medium
2

Why might moving a route to the edge make it slower?

Hard
3

Why do serverless deployments need a database connection pooler?

Hard

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.

Loading discussion…