Edge vs Node for LLM and DB routes: limits and split patterns

“Edge” (Vercel Edge, Cloudflare Workers, some Nitro builds configured as edge) is not full Node: do not assume fs, child_process, native C++ addons, or arbitrary TCP sockets. Classic database drivers (pg, mysql2, better-sqlite3) need TCP or native bindings → usually Node only, not edge.

Outbound HTTP to LLM APIs (fetch to OpenAI/Anthropic) often works on edge, but you still hit CPU, wall-clock, and bundle size ceilings. Read current vendor limits (e.g. Vercel Edge limits, Cloudflare Workers limits)—they evolve.

Edge: what works well

• Lightweight JWT handling (verify with Web Crypto–friendly libs).
• Rewrites, A/B tests, geolocation headers, cached fetch.
• Proxying to a Node API that performs heavy I/O.
• Vendor calls via fetch with moderate payloads.

Node: what almost always needs it

• SQL ORMs/drivers with TCP pools, better-sqlite3, Prisma engines, BullMQ, ffmpeg, heavy sharp pipelines, local filesystem.
• Long streams or CPU work past edge budgets.
• Secret access patterns that edge does not mirror (provider-specific).

Recommended split pattern

Typical flow for auth + LLM + DB:

Client → Edge route (JWT check, light rate limit)
       → internal fetch to /api/node/… (pinned region)
       → Node: DB queries + LLM + logging

Edge trims latency for validation and routing; stateful work stays in Node where toolchains are mature.

Cold start and timeouts

Edge often shows lower cold start for tiny handlers; Node (serverless) may pay container boot + Prisma init. Measure p95 separately for /edge vs /node on the first request after idle—do not merge metrics.

Pre-deploy checklist

• Does this route import node: built-ins or native addons? → Node.
• Serial heavy subrequests? Consider all Node or batching.
• Edge max duration < LLM p95 latency? → Node or async (queue + callback).
• Need DB-facing WebSockets? → Node or managed relay.

Typical error message (Next.js / Vercel Edge)

Importing a Node-only module (fs, better-sqlite3, pg, …) into an Edge route often fails at build or runtime with text like (exact wording varies by Next version):

Error: A Node.js API is used (fs) which is not supported in the Edge Runtime.

Or during bundling, traces such as node:fs / “Module not found: Can't resolve 'fs'” from a transitive dependency. Next.js documents the class under Node.js Modules in Edge Runtime.

Fix: move the import to a Node route handler (or a Nitro server route on a Node preset) and keep edge limited to fetch / crypto / lightweight logic.

Vercel Edge: limits that affect LLM + DB paths

On Vercel Edge Functions you get Web-standard APIs (fetch, crypto, streams) but not full Node—aligned with Next.js guidance on Node.js modules in Edge Runtime. For numeric ceilings (CPU, wall time, streaming semantics) follow the live Edge limitations page: 2025 changelog posts discussed longer streaming durations (hundreds of seconds for the stream) while still enforcing time-to-first-byte budgets—re-read the current text before sizing LLM timeouts.

Vendor positioning: when you need native drivers or sustained CPU, roadmaps increasingly steer teams toward Node / Fluid compute; edge stays great for cheap routing / auth.

Nitro / Nuxt

In Nitro, routes are edge-capable only when the deployment preset allows it. A default node-server preset is Node—no implicit edge. If you later expose edge routes, explicitly document which handlers remain server-only (runtimeConfig, routeRules).

Summary

fetch-only, stateless, low CPU → edge candidate. DB drivers, slow LLM, filesystem, natives → Node. Edge → internal Node is the pragmatic default for many multi-tenant SaaS APIs.