Edge runtime o Node runtime: qué cambia en Next.js 16

El Edge runtime es un entorno V8 isolate que ejecuta el código en más de 300 Points of Presence con arranques en frío por debajo de 100ms; el Node runtime es un proceso Node.js completo que corre en data centers regionales con un acceso más amplio a APIs y un coste de arranque mayor. Resuelven problemas distintos, y la respuesta correcta para un SaaS casi nunca es "todo Edge" ni "todo Node".

Este artículo es para responsables de ingeniería que eligen runtime por ruta en Next.js 16 o en cualquier framework que exponga el mismo split. Nos centramos en lo que de verdad rompe en producción, no en el marketing.

Qué ha cambiado: Next.js ha deprecado el Edge runtime

Desde Next.js 16.3, export const runtime = 'edge' está deprecado y la indicación oficial es borrar la línea: el default es Node.js y no hace falta ningún sustituto (Next.js: Edge Runtime Deprecated). Next.js 16 también ha renombrado middleware.ts a proxy.ts y el export middleware a proxy, y la función proxy corre solo en Node.js (Vercel: Routing Middleware). En Vercel, las Edge Functions están deprecadas a favor de las Vercel Functions en el runtime de Node.js, y ahora los dos runtimes corren sobre fluid compute con precios de Active CPU (Vercel: Edge Runtime).

Las contrapartidas de abajo siguen describiendo qué hace bien cada runtime, y siguen decidiendo rutas en Cloudflare Workers, Deno Deploy y en cualquier framework que mantenga el split. En Next.js y Vercel la decisión ya está tomada por ti: escribe para Node y lee la columna Edge como una superficie de restricciones que ya no tienes que esquivar.

TL;DR

Elige Edge para rutas cortas, sensibles a la latencia, que solo usan Web APIs: middleware, comprobaciones de auth, routing A/B, rewrites por geolocalización, relays de tokens en streaming. Elige Node para rutas que dependen de un paquete npm pesado, hablan con una base de datos SQL vía driver persistente, duran más de unos segundos, generan PDFs o tocan el sistema de archivos. Hasta que Next.js 16.3 quitó la elección, la mayoría de los SaaS que entregamos corrían middleware en Edge y APIs CRUD en Node, y solo ese split cubría el ~95% de las decisiones.

Comparativa de un vistazo

Dónde gana Edge

Latencia de cold start

El benchmark más citado en este tema, hecho por openstatus, midió 106ms P50 para Edge frente a 246ms warm y 859ms cold para Vercel serverless: 9x más rápido en cold paths y 2x cuando ya está warm (openstatus, 2024). La razón es estructural: los V8 isolates comparten un único proceso del SO, así que arrancar uno es una asignación de memoria por debajo del milisegundo. Una función serverless Node tiene que levantar un proceso Node, parsear node_modules y ejecutar el código de la aplicación: cientos de milisegundos incluso con un bundle pequeño. Ese benchmark es anterior a fluid compute, que Vercel aplica ya por defecto al runtime de Node con optimización de bytecode y pre-warming en los despliegues de producción: hoy la diferencia en caliente es más estrecha que en 2024 (Vercel: Fluid compute).

Para un middleware que corre en cada request, esto importa. Incluso 200ms de cold-start en un middleware de gating bastan para reventar tus objetivos de TTFB y empujar el Largest Contentful Paint a la zona amarilla.

Proximidad global

Las funciones Edge se ejecutan en el PoP más cercano al usuario. Una request desde São Paulo hacia una región Node solo en Frankfurt tarda 200+ms de red antes de que el código corra. La misma request hacia una función Edge aterriza en un PoP de São Paulo y el round-trip baja a 30ms. Para rutas cuya respuesta es "pon una cookie, redirige o reescribe", esos 200ms son todo el presupuesto de latencia.

Streaming de tokens desde un LLM

Los runtimes Edge implementan ReadableStream de forma nativa y la plataforma Vercel los reenvía al cliente sin bufferear. Para UIs de chat que streamean tokens desde Claude, GPT o Gemini, Edge mantiene baja la latencia percibida porque los tokens llegan al usuario según aterrizan en el PoP, no después de que una región Node los rebuffere.

Dónde gana Node

Compatibilidad de librerías

Edge ejecuta un subconjunto estricto de Web APIs. No hay fs, ni child_process, ni net, ni crypto nativo, ni eval, ni new Function(). Cualquier paquete npm que toque esas APIs, directa o transitivamente, no funciona (Next.js Edge API reference).

La lista de paquetes incompatibles es larga: jsonwebtoken, bcrypt, sharp, puppeteer, pdfkit, gran parte de los ORMs con drivers nativos, y cualquier paquete que use globals Node-specific. Algunos tienen hermanos edge-compatibles (jose para JWT, @node-rs/argon2 para hashing, el edge client de Prisma) pero la migración no es gratis, sobre todo cuando descubres el rewrite a mitad de una feature.

Acceso a base de datos

Las conexiones TCP persistentes a una base SQL no existen en Edge. El modelo es HTTP-based: cada consulta abre una conexión nueva por un proxy o un driver serverless. Funciona para patrones pequeños y read-heavy, pero transacciones, prepared statements y consultas largas son más lentas y caras que en Node. Lo vemos en la práctica con Supabase: una función serverless Node con cliente postgres en pool maneja una transacción de 6 statements en 40ms de rutina; lo equivalente vía API HTTP de Supabase desde Edge sube a 120-200ms.

Trabajo largo o intensivo en CPU

Las funciones Edge en Vercel deben empezar a streamear una respuesta dentro de 25 segundos, aunque la invocación total puede durar hasta 300s (Vercel, marzo 2025). Para generar PDFs, transformar imágenes, empaquetar ZIPs o cualquier trabajo CPU síncrono que bloquea antes de producir salida, Node es el runtime más seguro. La CPU también es más débil en Edge: los V8 isolates se planifican de forma agresiva y pueden ser desalojados, mientras que las funciones Node tienen un slot de ejecución dedicado.

Tamaño del bundle

El techo de bundle Edge en Vercel está entre 1 MB y 4 MB según el plan y la plataforma, e incluye todo lo importado de forma transitiva (Vercel Functions Limits). Un SDK mediano basta para reventarlo. Las funciones Node llegan a 250 MB sin comprimir: rara vez un cuello de botella.

La cuestión del middleware, que ahora es la del proxy

Durante dos años el middleware de Next.js fue solo Edge. Eso obligaba a los equipos a hacer auth checks contra un store de sesión HTTP-based (Upstash, Clerk, JWT de Auth.js) y a evitar cualquier dependencia Node-specific en el path del middleware. En Next.js 15.5, Vercel hizo estable el soporte de Node.js runtime para middleware tras la fase experimental en 15.2 (notas de release de Next.js 15.5). Con Next.js 16 se ha ido más lejos.

El efecto práctico: ahora puedes correr una librería solo-Node (un validador de sesión que necesita crypto, un cliente ORM, un SDK de feature flags que usa fs) en el middleware sin malabares con Edge polyfills. La contrapartida es la regresión de cold-start: el middleware Node arranca más lento que el Edge, y donde el middleware Edge sigue existiendo es justo ese coste el que justifica dejar ahí las rutas de gating con mucho tráfico.

Next.js 16 cerró la cuestión renombrando el archivo. middleware.ts pasó a ser proxy.ts, el export middleware pasó a ser proxy, y dentro de ese archivo el segment config runtime se rechaza: el proxy corre siempre en Node.js (Next.js: proxy). Vercel construye el Routing Middleware sobre fluid compute, que lleva optimización de bytecode y pre-warming en producción al camino de Node: con eso se fue buena parte de la vieja ventaja de cold start de Edge.

Nuestra vieja regla, middleware Edge como default, en Next.js 16 ya no tiene palanca que accionar. Escribe el proxy para Node y mantenlo fino: lee una cookie, redirige, pon una cabecera. El cambio de nombre es el framework diciéndote que no metas ahí la lógica de la aplicación.

Lo que de verdad corremos en producción

El split que entregamos en la mayoría de los proyectos SaaS de Studio:

• Edge: middleware (routing i18n, auth gate, A/B, geolocalización), /api/health, endpoints de image rewrite, relays de streaming LLM, endpoints de lectura de bajo riesgo contra Upstash Redis.
• Node: todo el CRUD admin contra Supabase, subida de archivos a R2, webhooks de Stripe, generación de PDFs, cualquier cosa que toque el sistema de archivos, jobs programados.

El default para una ruta nueva es Node, y donde Edge sigue existiendo solo promovemos una ruta cuando medimos una ganancia de latencia que justifique la superficie de restricciones. En Next.js 16.3 y posteriores no hay nada que promover: todas las rutas salen en Node. "Default a Edge" es un error frecuente en SaaS en fase temprana: empuja auth y acceso a DB a un runtime donde son más lentos y caros, y luego empuja al equipo a un porting de 2 semanas a Node cuando un webhook de Stripe necesita correr 12 segundos.

El árbol de decisión

En una plataforma que todavía expone los dos runtimes, para una ruta nueva lo recorremos en este orden. En Next.js 16.3 y posteriores cada rama acaba en Node, así que el árbol se lee ya como el mapa de lo que te costaba la columna Edge, no como una decisión que tomas:

1. ¿La ruta tiene que leer la request y actuar en menos de 50ms (geolocalización, auth gate, rewrite)? Edge.
2. ¿La ruta hace streaming de tokens desde un LLM? Edge.
3. ¿La ruta depende de un solo paquete npm que tira de APIs Node? Node.
4. ¿La ruta hace una transacción DB de varios statements? Node.
5. ¿La ruta podría correr más de 25 segundos antes de empezar a streamear? Node.
6. ¿El bundle de la ruta ya pasa de 1 MB? Node.
7. ¿Nada de lo anterior y la ruta es de mucho tráfico? Edge, medido.
8. En cualquier otro caso: Node, por defecto.

Las decisiones tomadas así son reversibles. Las tomadas siguiendo "todo Edge, es más rápido" normalmente no lo son, porque cuando el equipo se choca con el muro media codebase ya está escrita solo contra Web APIs.

Actualizado 2026-06-03: restaurada la tabla comparativa (antes reducida a texto).

Actualizado 2026-09-13: Next.js ha deprecado el Edge runtime, así que desde 16.3 runtime = 'edge' se rechaza, middleware.ts es ahora proxy.ts y corre solo en Node, y Vercel ha movido los dos runtimes a fluid compute.