Cloudflare ha declarado Hyperdrive para MySQL en disponibilidad general (14 de octubre de 2026) y, de paso, ha publicado la autopsia de un bug de caché que devolvía filas vacías en torno al 0,001 % de las consultas. Si usas Workers con MySQL, la lección sobre cachés compartidas y capacidades del protocolo te sirve aunque nunca uses Hyperdrive.
Qué cambia
Hyperdrive es un pooler de conexiones distribuido que conecta Workers con bases de datos SQL: mantiene conexiones abiertas y las comparte entre peticiones, algo útil porque abrir una conexión cuesta al menos cinco viajes de ida y vuelta por la red. También puede cachear consultas comunes en la caché CDN global. Según Cloudflare, entre la beta de MySQL y la GA hay "20 bug fixes", y el objetivo durante la beta fue validar una disponibilidad del 99,99 %.
Cada instancia tiene dos nodos. El Client corre junto al Worker, gestiona la caché local (si está activa) y reenvía consultas al Endpoint, que mantiene el pool cerca de la base de datos. Ambos usan la caché CDN de su centro de datos, así que si coinciden en datacenter, comparten caché.
El bug: los resultados vacíos solo aparecían con la caché habilitada. El Client cacheaba los bytes exactos que escribía al Worker, ya traducidos a las capacidades de ese driver, mientras que el Endpoint trabaja siempre con las capacidades internas de Hyperdrive. La diferencia concreta era CLIENT_DEPRECATE_EOF, que mysql2 no soporta y por la que Hyperdrive reescribe los paquetes EOF/OK del conjunto de resultados. Había dos casos: si el Endpoint cacheaba y el Client leía, este respondía al Worker con bytes en formato Hyperdrive sin traducir; si el Client cacheaba y otro nodo leía, se traducía dos veces y acababa en un EOF prematuro o un bloqueo.
El arreglo: guardar siempre una versión canónica de los bytes del resultado, codificada con las capacidades de Hyperdrive, sea cual sea el nodo que la escribe. Tras el cambio desaparecieron las filas vacías y la tasa de éxito de conexiones del Client llegó al 99,99 %.
También cuentan dos trampas de MySQL: utf8 es un alias obsoleto de utf8mb3 (1 a 3 bytes por carácter), así que migraron a utf8mb4 para soportar emojis; y COM_RESET_CONNECTION devuelve la conexión al valor por defecto del servidor, no al negociado en el handshake (por ejemplo latin1 en lugar de utf8mb4), por lo que hay que volver a fijar el charset tras cada reset.
Por qué importa en producción
Un fallo del 0,001 % no salta en ningún test ni en un dashboard de tasa de errores; lo ves cuando un usuario recibe una lista vacía que no debería estar vacía. Dos cosas me parecen relevantes. Primera: si cacheas una respuesta en un punto intermedio, la clave de caché tiene que incluir todo lo que condicione su codificación, o guardas un formato canónico. Guardar "lo que le mandé al cliente" mezcla representación y contenido. Segunda: una GA con 20 correcciones respecto a la beta es una señal honesta de madurez, pero también recuerda que el caso raro es el que cuesta encontrar.
No hay precios en el artículo, así que no puedo decir nada sobre coste.
Qué haría yo
- Si tengo Workers con MySQL, probar Hyperdrive en un entorno de staging con la caché activa y comparar resultados con la consulta directa a la base de datos.
- Revisar que mis conexiones usan
utf8mb4y no el aliasutf8, y que cualquier pool que haga reset de conexión vuelve a fijar el charset. - Añadir una comprobación sintética de "consulta que nunca debería ser vacía" para detectar este tipo de regresión con cachés.
- En mis propias cachés, almacenar una representación canónica, no los bytes específicos de cada cliente.
Fuentes
- Cloudflare Blog, "Inside Hyperdrive" (14-10-2026): https://blog.cloudflare.com/hyperdrive-mysql/