Cloudflare Hyperdrive conecta Python Workers ao PostgreSQL e MySQL

Com o Cloudflare Hyperdrive, o banco pode ficar onde está

O mais útil dessa novidade é justamente o que deixa de ser necessário migrar.

O Hyperdrive é uma camada gerenciada de conexão entre um Cloudflare Worker e um banco PostgreSQL ou MySQL já existente. Ele não é um banco novo nem copia seus registros para a Cloudflare. O código Python abre uma conexão TCP com um driver de banco convencional, usando os dados de conexão fornecidos por um binding do Hyperdrive. Nos bastidores, o Hyperdrive administra o pool de conexões persistentes com o banco.

Isso muda uma solução de contorno bastante comum. Quando um Python Worker não conseguia acessar o banco diretamente, ele podia chamar uma pequena API ou um servidor cuja única função era executar SQL. O caminho era este:

Antes: Python Worker → ponte de banco de dados → PostgreSQL ou MySQL

Agora: Python Worker → Hyperdrive → PostgreSQL ou MySQL

A Cloudflare inicia a conexão perto do Worker e mantém as conexões do pool próximas ao banco de origem. O guia do Hyperdrive contabiliza sete viagens de ida e volta em uma configuração convencional antes da primeira consulta: uma para TCP, três para TLS e três para autenticação no banco. Reaproveitar o pool evita repetir toda essa preparação a cada execução curta do Worker.

O caminho compatível é bem específico. Python Workers precisam usar uma data de compatibilidade igual ou posterior a 2026-09-08, e o recurso ainda está em beta. Para PostgreSQL, a Cloudflare testou asyncpg, pg8000 e psycopg; para MySQL, aiomysql e pymysql. Os drivers recomendados são asyncpg e aiomysql.

Segundo a Cloudflare, outros drivers TCP também podem funcionar. Isso não significa que qualquer pacote, ORM ou aplicação existente esteja garantido. A compatibilidade com o banco leva você apenas até a primeira etapa, não até o fim da migração.

O que muda na conta

A economia mais evidente aparece quando a aplicação Python já roda em Workers e você paga por uma ponte apenas porque o Worker precisa acessar o banco.

A conta é simples:

Custo mensal atual = banco de dados + Worker + hospedagem da ponte

Custo mensal possível = banco de dados + Worker

A cobrança do banco continua. O pool de conexões e o cache de consultas nativos do Hyperdrive não geram uma tarifa separada no Workers Paid, e o Hyperdrive não cobra por egress. Se a conta já estiver dentro do uso incluído de Workers, o custo adicional da Cloudflare para esse caminho de conexão será, portanto, $0. A economia financeira possível é a hospedagem da ponte que efetivamente deixar de existir.

A manutenção entra na mesma conta. Remover a ponte também pode eliminar um deploy, uma verificação de integridade, um conjunto de segredos, um fluxo de logs e um ponto de falha. Só atribua um valor financeiro a esse trabalho depois de saber quem faz a manutenção e com que frequência ela causa problemas.

Para uma conta paga nova, o Workers Paid começa em $5 por conta por mês. O plano inclui 10 milhões de requisições e 30 milhões de milissegundos de CPU por mês. O excedente custa $0.30 por milhão adicional de requisições e $0.02 por milhão adicional de milissegundos de CPU. Nesse plano, as consultas ao banco via Hyperdrive são listadas como ilimitadas.

O plano Free dá conta de uma prova de conceito pequena. Ele inclui 100,000 requisições ao Worker por dia e 100,000 consultas ao banco via Hyperdrive por dia, com 10 milissegundos de CPU por execução. São contadores separados. Uma única requisição que execute várias instruções SQL pode consumir várias consultas ao banco.

Quem pode aproveitar a mudança já

Um fundador solo com um serviço FastAPI

Imagine um fundador com um Worker FastAPI na frente de um banco PostgreSQL gerenciado, além de um pequeno contêiner que recebe chamadas HTTP e executa SQL. Se esse contêiner não tiver nenhuma lógica de negócio, um teste com asyncpg pode mostrar se o Hyperdrive consegue substituí-lo.

O ganho não está em adotar um banco novo. Está em manter o esquema, os backups e o provedor atuais enquanto se elimina um serviço que só existia como adaptador de conexão. Primeiro, o fundador deve migrar uma rota e comparar o resultado e a latência; a ponte só deve ser removida quando o comportamento em produção for equivalente.

Uma pequena agência com bancos MySQL de clientes

Uma agência pequena pode manter várias APIs Python enxutas, cada uma conectada ao banco MySQL de um cliente. Com o novo caminho, ela pode testar aiomysql ou pymysql dentro do Worker, em vez de implantar um proxy de banco ao lado de cada aplicação compatível.

O benefício é a consistência operacional. A agência pode adotar um único fluxo de deploy para Workers e uma configuração do Hyperdrive por banco. A ponte continua necessária quando cuida de autorização entre tenants, tradução de esquema, auditoria ou qualquer outra tarefa além de simplesmente encaminhar consultas.

Uma equipe de plataforma migrando um endpoint com muitas leituras

Uma equipe de plataforma não precisa migrar todo o backend. Ela pode levar para Workers um único endpoint Python público e intensivo em leitura, manter o banco regional e deixar que o Hyperdrive gerencie o pool de conexões na origem.

É também nesse cenário que o cache exige uma decisão explícita. Por padrão, o Hyperdrive armazena em cache as leituras elegíveis por 60 segundos e pode entregar um resultado desatualizado por mais 15 segundos enquanto faz a revalidação. Leituras públicas de catálogo ou conteúdo talvez tolerem esse comportamento. Autenticação, permissões, estado de cobrança e leituras logo após uma gravação devem usar uma configuração separada do Hyperdrive, com o cache desativado.

A comparação anterior entre Django e FastAPI ainda ajuda na escolha do framework. Esta novidade muda uma parte da decisão: manter PostgreSQL ou MySQL agora é um caminho documentado para Python Workers, mas isso não garante o restante de uma aplicação Django ou FastAPI.

Monte o menor teste de conexão que seja seguro

Use um banco MySQL fora de produção e um usuário de teste com permissões limitadas. O objetivo é comprovar o caminho da conexão com SELECT 1, não ensaiar uma migração completa usando dados de clientes.

Crie uma configuração do Hyperdrive sem cache para que o primeiro teste meça uma ida e volta ao banco sem dados reaproveitados:

npx wrangler hyperdrive create python-db-test --connection-string="mysql://user:password@HOSTNAME_OR_IP_ADDRESS:PORT/database_name" --caching-disabled

Copie para o wrangler.toml o ID da configuração exibido pelo Wrangler. A data abaixo é posterior ao mínimo obrigatório 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>"

Adicione o driver ao pyproject.toml:

[project]
dependencies = [
    "aiomysql",
]

Depois, use em src/main.py o teste de conexão documentado pela 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()

Faça o deploy com o comando documentado para Python Workers:

uv run pywrangler deploy

A linha que costuma parecer errada é ssl=None. No exemplo da Cloudflare, ela configura a conexão do driver entre o Worker e o Hyperdrive. A conexão do Hyperdrive com o banco de origem continua exigindo TLS, e conexões de origem inseguras em texto simples não são compatíveis.

A ponte se tornou opcional, não automaticamente obsoleta

O lançamento muda o caminho da conexão. Ele não transforma Python Workers em um servidor CPython sem restrições.

O suporte a pacotes Python abrange pacotes escritos inteiramente em Python, wheels PyEmscripten e pacotes incluídos no Pyodide. A Cloudflare ainda considera inicial o suporte a pacotes WebAssembly, portanto uma dependência ausente pode impedir a migração. A documentação de drivers e ORMs atualmente oferece suporte apenas ao SQLAlchemy síncrono. O SQLAlchemy assíncrono não é compatível porque o ambiente Workers não oferece suporte a greenlet.

O protocolo do banco também impõe limites. O Hyperdrive é compatível com PostgreSQL 9.0 a 17.x, MySQL 5.7 a 8.x e MariaDB. Não há suporte para SQL Server nem MongoDB. Advisory locks do PostgreSQL e LISTEN ou NOTIFY ficam de fora. No MySQL, consultas com várias instruções e prepared statements no nível do protocolo também não são compatíveis. Tanto no Free quanto no Paid, a duração máxima de uma consulta é de 60 segundos.

O pool também muda as premissas de sessão. O Hyperdrive usa transaction pooling, ou seja, a conexão com a origem volta para o pool quando a transação termina. É preciso revisar códigos que esperam preservar o estado da sessão entre transações. Transações longas também podem esgotar o pool e anular o ganho de concorrência.

O teste para a próxima segunda-feira

Não migre a aplicação inteira na segunda-feira. Primeiro, comprove se uma ponte dedicada apenas ao banco realmente precisa continuar existindo.

Tome uma atitude nesta semana se a ponte existir apenas para acesso ao banco, a aplicação usar PostgreSQL ou MySQL e a rota estiver coberta por um driver testado. Espere se você depende de SQLAlchemy assíncrono, de um pacote indisponível, de comportamento SQL não compatível ou de consistência rigorosa de leitura após gravação que ainda não foi isolada. Nada muda para quem pretende manter a aplicação no servidor atual ou para quem usa a ponte com uma lógica de negócio que o Hyperdrive não substitui.

Para receber a próxima mudança de plataforma convertida em uma decisão prática para segunda-feira, assine a newsletter.