Cloudflare Workers Python: conecta bases de datos con Hyperdrive
Cloudflare Workers Python ya se conecta a PostgreSQL y MySQL mediante Hyperdrive. Qué cambia, cuánto cuesta y cómo probarlo sin arriesgar producción.

El 16 de septiembre de 2026, Cloudflare habilitó una ruta directa entre Cloudflare Workers Python y las bases de datos PostgreSQL o MySQL mediante Hyperdrive. Si un Worker necesitaba un servicio HTTP separado solo para acceder a una base de datos existente, ahora podría prescindir de él. El cambio afecta tanto a la arquitectura como a la factura mensual.
¿Cómo conecta Cloudflare Workers Python con una base de datos existente?
Lo valioso de este lanzamiento es aquello que ya no hace falta trasladar.
Hyperdrive es una capa administrada de conexión entre un Cloudflare Worker y una base de datos PostgreSQL o MySQL existente. No es una base de datos nueva ni copia los registros en Cloudflare. El código Python abre una conexión TCP con un controlador de base de datos convencional y utiliza los datos de conexión proporcionados por un binding de Hyperdrive. A su vez, Hyperdrive administra el pool de conexiones persistentes con la base de datos.
Esto modifica una solución alternativa muy habitual. Cuando un Python Worker no podía acceder directamente a su base de datos, podía llamar a una API pequeña o a un servidor cuya única tarea fuera ejecutar SQL. La ruta era esta:
Antes: Python Worker → puente de base de datos → PostgreSQL o MySQL
Ahora: Python Worker → Hyperdrive → PostgreSQL o MySQL
Cloudflare establece la conexión cerca del Worker y mantiene las conexiones agrupadas cerca de la base de datos de origen. Su guía de Hyperdrive contabiliza siete viajes de ida y vuelta en una configuración convencional antes de la primera consulta: uno para TCP, tres para TLS y tres para autenticar la base de datos. Reutilizar el pool evita repetir toda esa secuencia con cada invocación breve del Worker.

La ruta compatible tiene requisitos concretos. Los Python Workers necesitan una fecha de compatibilidad 2026-09-08 o posterior, y la función todavía está en beta. Cloudflare ha probado asyncpg, pg8000 y psycopg para PostgreSQL, además de aiomysql y pymysql para MySQL. Los controladores recomendados son asyncpg y aiomysql.
Cloudflare señala que otros controladores TCP podrían funcionar. Eso no equivale a garantizar que cualquier paquete, ORM o aplicación existente vaya a hacerlo. La compatibilidad con la base de datos permite llegar a la primera barrera, no completar toda la migración.
El costo que ahora puede desaparecer
El ahorro más evidente surge cuando la aplicación Python ya se ejecuta en Workers y se paga un puente únicamente porque el Worker necesita acceso a la base de datos.
La cuenta es sencilla:
Costo mensual actual = base de datos + Worker + alojamiento del puente
Costo mensual posible = base de datos + Worker
La factura de la base de datos no cambia. El pool de conexiones y la caché de consultas integrados en Hyperdrive no tienen un cargo adicional en Workers Paid, y Hyperdrive tampoco cobra por tráfico saliente. Si la cuenta ya se mantiene dentro del uso incluido de Workers, el incremento de Cloudflare por esta vía de conexión es, por tanto, de $0. El ahorro económico posible corresponde a la factura del alojamiento del puente que realmente se elimine.
El mantenimiento forma parte del mismo cálculo. Quitar el puente también puede eliminar un despliegue, una comprobación de estado, un conjunto de secretos, un flujo de registros y un punto de fallo. No conviene asignar un valor monetario a ese trabajo hasta saber quién lo mantiene y con qué frecuencia causa problemas.
Para una cuenta de pago nueva, Workers Paid comienza en $5 por cuenta al mes. Incluye 10 millones de solicitudes y 30 millones de milisegundos de CPU al mes. El excedente cuesta $0.30 por cada millón de solicitudes adicionales y $0.02 por cada millón de milisegundos de CPU adicionales. En ese plan, las consultas de base de datos de Hyperdrive figuran como ilimitadas.
El plan Free permite hacer una prueba pequeña. Incluye 100,000 solicitudes de Worker al día y 100,000 consultas de base de datos de Hyperdrive al día, con 10 milisegundos de CPU por invocación. Son contadores independientes. Una solicitud que ejecute varias sentencias SQL puede consumir varias consultas de base de datos.
Quién puede aprovecharlo desde mañana
Un fundador independiente con un servicio FastAPI
Pensemos en un fundador que tiene un Worker con FastAPI delante de una base de datos PostgreSQL administrada, además de un contenedor pequeño que recibe llamadas HTTP y ejecuta SQL. Si ese contenedor no contiene lógica de negocio, una prueba con asyncpg puede demostrar si Hyperdrive permite sustituirlo.
La ventaja no es una base de datos nueva, sino conservar el esquema, las copias de seguridad y el proveedor actuales mientras se elimina un servicio que solo existía como adaptador de conexión. Lo prudente es migrar primero una ruta, comparar su resultado y su latencia, y retirar el puente cuando el comportamiento en producción coincida.
Una agencia pequeña con bases de datos MySQL de clientes
Una agencia pequeña puede mantener varias API acotadas en Python, cada una conectada a la base de datos MySQL de un cliente. La nueva ruta permite probar aiomysql o pymysql dentro del Worker, en lugar de desplegar un proxy de base de datos junto a cada aplicación que cumpla los requisitos.
El beneficio es la consistencia operativa. La agencia puede utilizar una sola ruta de despliegue de Workers y una configuración de Hyperdrive por base de datos. El puente debe conservarse si gestiona la autorización de cada tenant, transforma esquemas, realiza auditorías o cumple cualquier otra función además de transferir consultas.
Un equipo de plataforma que migra un endpoint de lectura intensiva
Un equipo de plataforma no necesita migrar todo el backend. Puede trasladar a Workers un único endpoint público de Python con muchas lecturas, conservar la base de datos regional y dejar que Hyperdrive agrupe las conexiones al origen.
En este escenario, la caché también exige una decisión explícita. De forma predeterminada, Hyperdrive almacena en caché las lecturas aptas durante 60 segundos y puede servir un resultado obsoleto durante otros 15 segundos mientras lo revalida. Las lecturas públicas de catálogos o contenidos quizá toleren ese comportamiento. La autenticación, los permisos, el estado de facturación y las lecturas inmediatamente posteriores a una escritura deberían utilizar una configuración separada de Hyperdrive con la caché desactivada.
La anterior comparación entre Django y FastAPI sigue siendo útil para elegir el framework. Este lanzamiento cambia una parte de esa decisión: mantener PostgreSQL o MySQL ya es una ruta documentada para Python Workers, pero no certifica el resto de una aplicación con Django o FastAPI.
Cómo crear la prueba de conexión mínima y segura
Conviene usar una base de datos MySQL que no sea de producción y un usuario de prueba con permisos limitados. El objetivo es validar la ruta de conexión con SELECT 1, no ensayar una migración completa con datos de clientes.
Cree una configuración de Hyperdrive con la caché desactivada para que la primera prueba mida un recorrido nuevo hasta la base de datos:
npx wrangler hyperdrive create python-db-test --connection-string="mysql://user:password@HOSTNAME_OR_IP_ADDRESS:PORT/database_name" --caching-disabledCopie en wrangler.toml el ID de configuración que entrega Wrangler. La fecha siguiente es posterior al mínimo obligatorio de 2026-09-08:
name = "python-hyperdrive"
main = "src/main.py"
compatibility_date = "2026-09-16"
compatibility_flags = ["python_workers"]
[[hyperdrive]]
binding = "HYPERDRIVE"
id = "<HYPERDRIVE_CONFIG_ID>"Añada el controlador a pyproject.toml:
[project]
dependencies = [
"aiomysql",
]Después, utilice en src/main.py la prueba de conexión documentada por Cloudflare:
import aiomysql
from workers import Response, WorkerEntrypoint
class Default(WorkerEntrypoint):
async def fetch(self, request):
hd = self.env.HYPERDRIVE
connection = await aiomysql.connect(
host=hd.host,
port=int(hd.port),
user=hd.user,
password=hd.password,
db=hd.database,
ssl=None,
)
try:
cursor = await connection.cursor()
await cursor.execute("SELECT 1")
result = await cursor.fetchone()
return Response.json({"result": result[0]})
finally:
connection.close()Despliegue el Worker con el comando documentado para Python Workers:
uv run pywrangler deployLa línea que suele parecer incorrecta es ssl=None. En el ejemplo de Cloudflare, corresponde a la conexión del controlador entre el Worker y Hyperdrive. La conexión de Hyperdrive con la base de datos de origen sigue requiriendo TLS; no se admiten conexiones de origen inseguras en texto plano.
El puente es opcional, pero no queda obsoleto automáticamente
El lanzamiento cambia una ruta de conexión. No convierte Python Workers en un servidor CPython sin restricciones.
La compatibilidad con paquetes de Python abarca paquetes de Python puro, wheels de PyEmscripten y paquetes incluidos en Pyodide. Cloudflare todavía califica como preliminar la compatibilidad con paquetes WebAssembly, de modo que una dependencia ausente puede frenar la migración. La documentación sobre controladores y ORM solo admite por ahora SQLAlchemy síncrono. SQLAlchemy asíncrono no es compatible porque el entorno de Workers carece de soporte para greenlet.
El protocolo de la base de datos también tiene límites. Hyperdrive admite PostgreSQL desde 9.0 hasta 17.x y MySQL desde 5.7 hasta 8.x, además de MariaDB. No admite SQL Server ni MongoDB. Quedan fuera los bloqueos consultivos de PostgreSQL y LISTEN o NOTIFY. También quedan fuera las consultas MySQL de varias sentencias y las sentencias preparadas en el nivel del protocolo. Tanto en Free como en Paid se aplica una duración máxima de consulta de 60 segundos.
El pooling también cambia los supuestos sobre las sesiones. Hyperdrive emplea pooling de transacciones, por lo que la conexión de origen vuelve al pool cuando termina la transacción. Hay que revisar el código que espera conservar el estado de sesión entre transacciones. Las transacciones largas también pueden agotar el pool y anular la ventaja de concurrencia.
La decisión del lunes
El lunes no hace falta migrar la aplicación. Primero hay que demostrar si tiene sentido conservar un puente dedicado exclusivamente a la base de datos.
Elija una ruta desechable
Cree una base de datos o réplica que no sea de producción y asígnele un usuario con permisos limitados. Elija una ruta que lea un registro inofensivo y que no dependa del estado de la sesión, de bloqueos ni de que una lectura refleje de inmediato una escritura.
Ejecute la prueba rápida de conexión
Despliegue el Worker pequeño del ejemplo y confirme que
SELECT 1funciona mediante Hyperdrive. Registre la tasa de errores del Worker, el tiempo de CPU, el tiempo transcurrido y el número de conexiones a la base de datos.Pruebe el controlador y la consulta reales
Sustituya la consulta de prueba por el controlador real de la ruta y una consulta representativa. Compare con el puente actual los datos devueltos, el comportamiento de las transacciones, la configuración de caché y el uso del pool.
Calcule el valor de eliminar el puente
Anote la factura mensual de alojamiento del puente y las horas dedicadas a desplegarlo, actualizarlo, supervisarlo y recuperarlo. Reste cualquier uso adicional de Workers y el trabajo continuo de Hyperdrive. Elimine el puente solo cuando tanto ese resultado como la prueba de compatibilidad sean favorables.
Vale la pena actuar esta semana si el puente solo sirve para acceder a la base de datos, la aplicación usa PostgreSQL o MySQL y un controlador probado cubre la ruta. Es mejor esperar si depende de SQLAlchemy asíncrono, de un paquete no disponible, de funciones SQL no compatibles o de una consistencia estricta de lectura tras escritura que aún no se haya separado. El cambio no afecta a las aplicaciones que permanecerán en su servidor actual ni a los puentes con lógica de negocio que Hyperdrive no sustituye.
Para recibir la próxima novedad de plataforma convertida en una decisión práctica para el lunes, suscríbase al boletín.
- Última actualización
- 16 sept 2026
- Categoría
- Explained







