Comparativa 2026 de edge runtimes: Workers, Deno Deploy y Vercel Functions

Hicimos pruebas reales en cinco regiones durante dos semanas comparando Cloudflare Workers, Deno Deploy y Vercel Functions en condiciones de carga similares a las de una API de producción. Los resultados desmontan algunos mitos persistentes y confirman otros. Aquí está lo que encontramos.

La premisa del edge computing para aplicaciones web es atractiva: en lugar de tener tu API en us-east-1 y que usuarios de Tokyo paguen 200ms de latencia extra, el código corre cerca del usuario. Pero "cerca del usuario" tiene matices importantes dependiendo de la plataforma.

Metodología

Probamos desde cinco regiones: Tokio, São Paulo, Frankfurt, Lagos y Chicago. Cada plataforma recibió el mismo código: un handler que lee de KV, hace una operación de transformación de datos y devuelve JSON. Medimos p50, p95 y p99 de latencia desde el cliente, tiempo de cold start y comportamiento bajo carga sostenida de 1.000 req/s.

Resultados por plataforma

Cloudflare Workers ganó en latencia p50 en todas las regiones excepto Lagos, donde su cobertura es más escasa. El cold start es virtualmente inexistente (< 5ms) gracias a V8 Isolates. El límite de 128MB de memoria por worker es restrictivo para algunas cargas. El ecosistema de bindings (KV, R2, D1, Queues) es el más maduro.

Deno Deploy sorprendió con la mejor latencia p99 en Frankfurt y Tokio. La integración con el ecosistema npm es más fluida de lo que esperábamos. El punto débil es la cobertura de regiones: 35 regiones frente a 310+ de Cloudflare. En Lagos, los números eran malos.

Vercel Functions (Edge Runtime) tiene la integración más fluida si ya usas Next.js — el DX es difícil de batir. En latencia pura quedó tercero en la mayoría de escenarios, pero la diferencia práctica en p50 era de menos de 10ms en los mercados principales. Donde sí perdió claramente fue en p99 bajo carga alta.

El mito que más se repite

La idea de que "edge siempre es más rápido" es falsa en muchos casos reales. Si tus datos viven en una base de datos centralizada en us-east-1, el edge solo mueve la latencia de red del cliente al servidor — pero luego el worker todavía tiene que ir a buscar los datos a us-east-1. Para cargas donde la mayor parte del tiempo es I/O a una DB centralizada, el edge puede ser incluso más lento que una región normal bien elegida.