El 11 de noviembre de 2026, Cloudflare aumentó dos límites de Hyperdrive, el servicio que mantiene un pool de conexiones (un conjunto de conexiones reutilizadas) y una caché de consultas entre Workers y bases PostgreSQL o MySQL alojadas fuera de Cloudflare. En el plan Workers Paid, cada cuenta puede tener hasta 100 configuraciones, antes eran 25, y cada configuración puede abrir hasta 1.500 conexiones con la base de origen, antes eran 100.
Qué cambió en Workers Paid
Una configuración de Hyperdrive apunta a una base concreta y define, entre otras cosas, cuántas conexiones puede mantener abiertas el pool con ella. Esas conexiones se comparten entre todas las invocaciones del Worker, y cada invocación ocupa una mientras dura su transacción. Con un techo de 100, una aplicación con muchas transacciones simultáneas chocaba con el límite de Hyperdrive antes que con el de la base.
El valor de cada configuración lo sigue eligiendo el equipo, hasta ese máximo, en el panel, con Wrangler (wrangler hyperdrive update <ID> --origin-connection-limit=<N>) o por la API REST. El anuncio no trae cambios para el plan Free.
Quién debe revisarlo
El cambio interesa a quien ejecuta aplicaciones en Workers con una base relacional fuera de Cloudflare, como Postgres o MySQL gestionados en otro proveedor. Dos perfiles ganan más.
El primero es la aplicación con mucho tráfico y transacciones largas, que encolaba peticiones esperando una conexión libre o tenía que repartir la carga entre varias configuraciones apuntando a la misma base para esquivar el techo. Con el techo nuevo, ese reparto puede dejar de ser necesario.
El segundo es el equipo que usa muchas bases separadas: una por cliente, por entorno o por rama de prueba. Con 25 configuraciones por cuenta, dar a cada preview su propia base agotaba la cuota rápido. Con 100, aislar la base de prueba se vuelve viable en más casos, lo que pesa en la decisión que trata Un preview seguro debe aislar los recursos conectados.
Qué hacer ahora
El anuncio no menciona ajuste automático de las configuraciones existentes ni plazo. Antes de subir el número, conviene comprobar cuántas conexiones acepta la base. La documentación de Cloudflare recomienda dejar el límite de Hyperdrive por debajo del max_connections de la base por dos motivos:
- el límite es flexible: durante fallos de red Hyperdrive puede abrir conexiones por encima de lo configurado para mantener la aplicación disponible, y necesita margen para ello;
- cuando varias configuraciones apuntan a la misma base, las conexiones de todas suman contra el mismo techo.
Las conexiones abiertas también consumen memoria en el servidor de la base. En PostgreSQL, el valor por defecto de max_connections suele ser 100, y el proveedor gestionado puede fijar otro según el plan, así que conviene consultar el número real de la instancia. En la práctica, el límite que pasa a pesar es el de la base y el del plan contratado con su proveedor. Si la aplicación ya sufría colas de conexión, lo prudente es subir el valor de a poco y vigilar el uso de conexiones y la latencia en la base, como sugiere la propia documentación.
Qué no está claro todavía
La página de límites de Hyperdrive aún mostraba los valores antiguos (25 configuraciones y cerca de 100 conexiones en Paid) cuando se escribió este texto, así que por ahora la referencia es el changelog. Ni el anuncio ni la guía de ajuste del pool indican el valor por defecto de conexiones para configuraciones nuevas; la guía dice que se consulte en la pantalla de configuración o en la respuesta de la API.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
