Michael JohnsonUma consulta ao Cloudflare D1 que retorna um resultado com mais de 50 MB falha desde 4 de novembro de 2026. Para quem desenvolve, é importante entender o alcance dessa mudança: ela diz respeito ao tamanho do resultado de uma consulta individual, não ao tamanho máximo do banco de dados. A importação e a exportação pela API REST não estão sujeitas a esse limite; portanto, a forma de ler os dados determina se será necessário alterar o fluxo de trabalho.
O que exatamente está limitado?
O Cloudflare descreveu a mudança em uma publicação de 30 de outubro: uma consulta cujo resultado exceda 50 MB retorna o erro D1 query result exceeded the maximum response size limit of 50 MB. A aplicação do limite começa em 4 de novembro de 2026. A documentação do D1 também indica que o limite se aplica ao tamanho do resultado da consulta; enquanto isso, o banco pode armazenar até 10 GB no plano pago ou 500 MB no plano gratuito.
São níveis diferentes: o armazenamento determina o volume de dados no banco, enquanto o limite de resultado determina quantos dados uma consulta pode retornar. Assim, um banco pode conter um volume de dados muito superior a 50 MB e continuar acessível para leituras em partes. Ao mesmo tempo, até mesmo uma consulta a um banco pequeno pode ultrapassar o limite se selecionar muitas linhas com muitos campos ou campos de texto e binários grandes.
No anúncio da Cloudflare sobre o limite, a empresa afirma que o limite abrange o percentil 99,999 das consultas D1. Essa é uma estimativa da distribuição de consultas fornecida pelo provedor; para uma verificação prática, é mais importante medir as respostas específicas do aplicativo e identificar as consultas que retornam grandes conjuntos de dados.
Por que a exportação pela API REST é um caso à parte?
Uma consulta do aplicativo geralmente recebe o resultado da execução de SQL e o repassa ao código que a chamou. A importação e a exportação do banco pela API REST são operações diferentes: a Cloudflare informa separadamente que elas não são afetadas pelo novo limite e continuam funcionando como antes. Portanto, uma falha em uma consulta grande não significa que seja impossível exportar um grande volume de dados do banco.
Na prática, essa distinção ajuda a escolher o caminho certo. Se o aplicativo precisa de todos os registros para exibição, processamento ou elaboração de um relatório, divida a leitura em lotes. Se o objetivo é transferir ou exportar dados, avalie o fluxo de exportação pela API REST em vez de tentar obter todo o banco em uma única resposta SQL.
Como reduzir a resposta sem perder os dados necessários?
O primeiro passo é remover as colunas desnecessárias. Em vez de SELECT *, especifique apenas os campos necessários para a operação em questão. Isso reduz o volume da resposta, especialmente se a tabela contiver descrições longas, valores JSON ou BLOB.
O segundo passo é ler as linhas em partes usando LIMIT e OFFSET, como recomenda a Cloudflare. Por exemplo, uma interface pode buscar a página seguinte conforme a pessoa rola a tela, enquanto uma tarefa em lote pode processar cada parte separadamente. Adicione uma ordenação estável, por exemplo, por identificador único: sem ela, os limites entre as páginas podem mudar se os dados forem alterados entre as consultas.
Em exportações longas, também vale a pena armazenar um ponto de controle correspondente ao último registro processado. Assim, é possível retomar a tarefa após uma falha sem processar todo o conjunto novamente. O esquema específico depende do aplicativo; o princípio fundamental é limitar o tamanho de cada resposta, em vez de depender de uma única consulta que retorne todo o conjunto de uma vez.
O que verificar no aplicativo
Comece pelas consultas que retornam listas grandes: exportações para relatórios, telas administrativas, tarefas em segundo plano e rotas de API que fornecem matrizes de linhas. Registre temporariamente o tamanho da resposta serializada ou a quantidade e o tamanho dos campos selecionados. Depois, verifique o volume máximo esperado, e não apenas o pequeno conjunto de dados normalmente usado nos testes.
Se o aplicativo apresentar um erro após a mudança, a documentação do D1 o associa especificamente a resultados acima de 50 MB e recomenda selecionar apenas as colunas necessárias ou dividir o resultado em páginas. Isso ajuda a distinguir um problema com o tamanho da resposta de limitações de tempo de execução, memória ou disponibilidade do banco: elas têm erros e causas diferentes.
A conclusão para a equipe é simples: provavelmente não será necessário alterar consultas comuns e curtas, mas leituras grandes devem ser convertidas para processamento em lotes. O limite não impede armazenar um banco maior nem bloqueia a exportação pela API REST; ele exige projetar consultas de modo que cada resposta permaneça dentro de 50 MB.
