A Cloudflare aumentou em 11 de novembro de 2026 dois limites do Hyperdrive, o serviço que mantém um pool de conexões (um conjunto de conexões reaproveitadas) e um cache de consultas entre Workers e bancos PostgreSQL ou MySQL hospedados fora da Cloudflare. No plano Workers Paid, cada conta pode ter até 100 configurações, antes eram 25, e cada configuração pode abrir até 1.500 conexões com o banco de origem, antes eram 100.
O que mudou no Workers Paid
Uma configuração do Hyperdrive aponta para um banco específico e define, entre outras coisas, quantas conexões o pool pode manter abertas com ele. Essas conexões são compartilhadas entre todas as invocações do Worker, e cada invocação ocupa uma delas enquanto dura a transação. Com teto de 100, uma aplicação com muitas transações simultâneas esbarrava no Hyperdrive antes de esbarrar no banco.
O valor de cada configuração continua sendo escolhido pela equipe, até esse máximo, no painel, pelo Wrangler (wrangler hyperdrive update <ID> --origin-connection-limit=<N>) ou pela API REST. O anúncio não traz mudança para o plano Free.
Quem precisa olhar para isso
A mudança interessa a quem roda aplicações em Workers com banco relacional fora da Cloudflare, como Postgres ou MySQL gerenciados em outro provedor. Dois perfis ganham mais com ela.
O primeiro é a aplicação com tráfego alto e transações longas, que enfileirava pedidos esperando conexão livre ou precisava dividir a carga entre várias configurações apontando para o mesmo banco para contornar o teto. Com o teto novo, essa divisão pode deixar de ser necessária.
O segundo é a equipe que usa muitas bases separadas: uma por cliente, por ambiente ou por branch de teste. Com 25 configurações por conta, dar a cada preview um banco próprio esgotava a cota rápido. Com 100, isolar o banco de teste fica viável em mais casos, o que pesa na decisão discutida em Um preview seguro precisa isolar os recursos conectados.
O que fazer agora
O anúncio não fala em ajuste automático das configurações existentes nem em prazo. Antes de subir o número, vale conferir quantas conexões o banco aceita. A documentação da Cloudflare recomenda deixar o limite do Hyperdrive abaixo do max_connections do banco por dois motivos:
- o limite é flexível: durante falhas de rede o Hyperdrive pode abrir conexões além do configurado para manter a aplicação disponível, e precisa de folga para isso;
- quando várias configurações apontam para o mesmo banco, as conexões de todas elas somam no mesmo teto.
Conexões abertas também consomem memória no servidor do banco. No PostgreSQL, o padrão de max_connections costuma ser 100, e o provedor gerenciado pode definir outro valor conforme o plano; vale consultar o número real da instância. Na prática, o limite que passa a pesar é o do banco e o do plano contratado com o provedor dele. Se a aplicação já sofria com fila de conexões, o caminho seguro é subir aos poucos e acompanhar uso de conexões e latência no banco, como a própria documentação sugere.
O que ainda não está claro
A página de limites do Hyperdrive ainda mostrava os valores antigos (25 configurações e cerca de 100 conexões no Paid) quando este texto foi escrito, então o changelog é a referência por enquanto. O anúncio e o guia de ajuste do pool também não dizem qual é o valor padrão de conexões para configurações novas; o guia indica conferir o número na tela de configurações ou na resposta da API.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
