5ms vs 200ms: Por Qué Cloudflare Workers Cambia lo que Puedes Construir (No Solo lo que Pagas)
Hay un número que me obsesiona últimamente: 5ms.
No es el tiempo de respuesta de una API bien optimizada. Es el cold start de un Cloudflare Worker. Y cuando lo pones al lado del cold start de AWS Lambda — entre 100ms y 200ms — algo hace clic.
Mira, durante mucho tiempo traté Cloudflare como una capa de CDN con descuento. La ponía delante de mis proyectos para cachear assets y ya. Error.
Lo que cambió mi perspectiva no fue un artículo ni un tweet. Fue un usuario que me preguntó por qué mi app tardaba “un momento” la primera vez que la usaba. Ese “momento” era el cold start de Lambda. Invisible para mí en desarrollo. Brutal para el usuario en producción.
Aquí está lo que realmente descubrí cuando empecé a mirar en serio.
El Problema Que Nadie Nombra Correctamente
Cuando la gente habla de Cloudflare Workers, la conversación siempre deriva hacia costes. 100.000 peticiones al día gratis, free tier generoso, R2 sin egress fees… todo eso es real y lo veremos.
Pero el argumento económico te hace pasar por alto algo más fundamental: Workers no funciona como Lambda. No levanta un contenedor. No inicializa un runtime de Node.js. Ejecuta código en V8 isolates — el mismo motor de JavaScript de Chrome — que ya está corriendo en los servidores de Cloudflare.
El resultado: cold starts por debajo de 5ms. Lambda oscila entre 100ms y 200ms.
Eso no es un 10% de mejora. Es un orden de magnitud diferente.
Y eso cambia qué tipo de productos puedes construir, no solo cuánto pagas.
El Ecosistema Que Nadie Te Cuenta Completo
Aquí es donde se pone interesante. Cloudflare no es solo Workers. Es un ecosistema completo que, bien usado en 2026, te permite construir aplicaciones full-stack sin salir del free tier.
Workers + KV: El Combo de Entrada
Workers KV te da 100.000 lecturas al día y 1GB de almacenamiento de forma gratuita. El caso de uso más práctico que he encontrado: rate limiting basado en TTL sin base de datos.
Sin Redis. Sin infraestructura extra. Sin coste adicional.
D1: SQLite en el Edge
D1 es SQLite en los servidores de Cloudflare, con réplicas de lectura gratuitas distribuidas globalmente. El patrón que más me gusta: una base de datos por tenant.
Aislamiento total entre clientes. Sin coste de réplicas de lectura. En 2026, para SaaS B2B con requisitos de datos europeos (GDPR relevante aquí), esto es una ventaja arquitectónica real.
R2: La Decisión Que Tiene Números Concretos
Aquí sí hay números que justifican el cambio: S3 cobra por egress — cada GB que sale de sus servidores tiene coste. R2 tiene egress a cero.
Si tienes una aplicación que sirve imágenes, vídeos, archivos — cualquier cosa pesada — la diferencia entre pagar por cada GB descargado y no pagar nada es brutal para la sostenibilidad del proyecto.
El caso documentado de migrar 50TB de S3 a R2 reportó más del 70% de ahorro en costes de ancho de banda. No lo inventé yo — es el caso de uso que Cloudflare documenta con sus propios usuarios.
Service Bindings: El Cambio Silencioso de 2025
El año pasado Cloudflare hizo algo importante: los Service Bindings son ahora gratuitos. Eso significa que puedes llamar a un Worker desde otro Worker sin coste adicional.
Esto desbloquea arquitecturas de microservicios sin que cada comunicación interna tenga coste. En Lambda, cada invocación tiene precio. Aquí no.
Lo Que Viene Gratis Sin Que Lo Pidas
Hay dos cosas del free tier de Cloudflare que la mayoría de developers no activa conscientemente porque simplemente están ahí:
DDoS Protection automática: El free plan incluye mitigación L7 automática. Cloudflare ha demostrado manejar picos de 106 millones de peticiones por segundo en ataques reales. Tu proyecto hereda esa infraestructura sin configurar nada.
Bot Fight Mode: Detección de bots con scores del 1 al 99, integrada con el WAF, disponible en el plan gratuito. Para un SaaS que está arrancando, tener esto desde el día uno es algo que plataformas enterprise cobran como feature premium.
Workers AI: El Siguiente Paso
En 2026, lo que más me llama la atención del ecosistema es Workers AI + Vectorize. La combinación permite construir RAG (Retrieval-Augmented Generation) directamente en el edge: un vector database con inferencia de LLMs en los mismos servidores donde ya corre tu lógica.
Lo que esto significa en la práctica: búsqueda semántica, agentes de IA, chatbots — sin saltar a un proveedor externo, con el free tier mensual incluido y AI Gateway para cachear respuestas y reducir costes.
Aún estoy explorando esto para mis proyectos actuales. No tengo números finales todavía. Pero la arquitectura tiene mucho sentido.
Por Dónde Empezar (Sin Parálisis)
No migres todo de golpe. Así es como yo lo haría desde cero en 2026:
Semana 1 — Prueba Workers con algo pequeño:
Desproyecta una API endpoint que ahora tienes en Vercel o Lambda. Mide los tiempos de respuesta.
Semana 2 — Evalúa R2 si tienes almacenamiento:
Mira tu factura actual de S3/cualquier storage. Calcula cuánto es egress. Si es una parte relevante del coste, R2 es movimiento directo.
Semana 3 — Añade D1 si tu proyecto tiene base de datos:
Un proyecto nuevo arranca directamente con D1. Uno existente puede migrar gradualmente tablas de solo lectura primero.
La Conclusión Real
Cloudflare no es solo la opción más barata. Es una arquitectura diferente que, para ciertos patrones de producto — APIs, aplicaciones globales, SaaS con múltiples tenants, apps que sirven mucho contenido estático — tiene ventajas técnicas que el coste no captura por sí solo.
5ms vs 200ms no es un número de marketing. Es la diferencia entre una app que se siente instantánea y una que se siente lenta en el primer uso.
En 2026, con el free tier actual, no hay razón para no probarlo.
Seguimos construyendo.
