Edge runtime vs Node runtime: cuándo elegir cada uno en un SaaS

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.

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. La mayoría de los SaaS que entregamos corren middleware en Edge y APIs CRUD en Node, y solo ese split cubre el ~95% de las decisiones.

Comparativa de un vistazo

EjeEdge runtimeNode runtimeMotorV8 isolate (subconjunto de Web APIs)Proceso Node.js completoCold start (P50)~100ms~250ms warm, ~860ms coldDistribución geográficaPoPs globalesUna o pocas regionesPaquetes npmSolo edge-compatibleCualquier paquete npmTamaño de bundle1 a 4 MB en VercelHasta 250 MB sin comprimirDuración máxima300s (streaming en 25s)Hasta 800s en Vercel ProSistema de archivosNingunoCompletoMódulos nativosNingunoSíConexiones persistentesNoSí (con matices)

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.

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 (Next.js 15.5+)

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). Next.js 16 mantiene este rumbo.

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, así que las ventajas de "middleware en Edge" siguen vigentes para rutas de gating con mucho tráfico.

Nuestra regla: middleware Edge como default; pasamos a middleware Node solo cuando la alternativa Edge requiere tres cambios de paquete edge-compatible para satisfacer una sola feature.

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 solo promovemos una ruta a Edge cuando medimos una ganancia de latencia que justifique la superficie de restricciones. "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

Frente a una ruta nueva lo recorremos en este orden:

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.