Resposta rápida
Desde 1º de setembro de 2026, consultas ao Cloudflare D1 no plano Workers Free falham quando a conta ultrapassa o limite diário de linhas lidas ou gravadas. O bloqueio vale para consultas feitas pela Workers Binding API e pela REST API e permanece até a cota ser reiniciada à meia-noite UTC. A Cloudflare afirma que os dados armazenados não são afetados.
Se o erro informa explicitamente que a conta excedeu o limite diário de row reads ou row writes, isso não significa, por si só, que o D1 caiu. É uma restrição da conta. A ação imediata é esperar o reinício da cota ou mudar para um plano pago; a correção duradoura é localizar consultas que leem ou gravam linhas demais.
Como reconhecer o erro de cota
A documentação lista duas mensagens específicas. Uma informa que a conta excedeu o limite diário de linhas lidas do plano gratuito; a outra, o limite diário de linhas gravadas. Ambas aparecem como D1_ERROR e orientam esperar até a meia-noite UTC ou fazer upgrade.
Leia a mensagem completa antes de alterar o código. Erros como Network connection lost, banco reiniciado, sobrecarga, tamanho máximo do banco ou SQL inválido têm causas e ações diferentes. Somente a mensagem de free tier daily row read limit ou free tier daily row write limit confirma que a cota diária foi esgotada.
- Registre a mensagem completa e o horário da falha, removendo dados pessoais e segredos.
- Identifique o banco, o Worker, a rota e a consulta associados à requisição.
- Confira o e-mail da conta: a Cloudflare informa que envia um alerta quando o limite diário é alcançado.
- Se a mensagem for de rede, reinício ou sobrecarga, trate-a como erro transitório; se citar o limite diário, não crie um ciclo de novas tentativas.
Por que poucas consultas podem ler muitas linhas
O D1 diferencia quantidade de consultas e quantidade de linhas percorridas. Os campos readQueries e writeQueries mostram o volume bruto de consultas e não são usados para cobrança. Já rowsRead contabiliza linhas examinadas e rowsWritten contabiliza linhas gravadas.
Uma consulta pode devolver um único resultado e ainda percorrer uma tabela inteira. Por isso, contar apenas requisições HTTP ou linhas retornadas não revela o consumo real. Filtros sem índice, joins mal planejados e buscas com curinga no início são padrões capazes de provocar varreduras amplas.
Como medir o consumo real no painel
No painel da Cloudflare, abra D1, escolha o banco e entre na aba Metrics. Compare rowsRead e rowsWritten com readQueries e writeQueries. Um crescimento muito maior de linhas lidas do que de consultas sugere que uma ou mais consultas estão examinando registros demais.
A documentação informa que as métricas ficam retidas por 31 dias. A resposta de cada consulta pela Workers Binding API também inclui contagens precisas de linhas lidas e gravadas no objeto meta, o que ajuda a vincular o aumento a um endpoint ou operação específica.
- Selecione o intervalo em que a cota foi atingida e descubra qual banco concentrou o aumento.
- Cruze o horário com logs, cron jobs, filas, agentes e rotas que consultam o D1.
- Registre rows_read e rows_written do meta das consultas mais frequentes.
- Priorize a consulta que combina alta frequência com mais linhas percorridas por execução.
Como encontrar uma varredura completa
Use EXPLAIN QUERY PLAN antes da consulta que você suspeita estar consumindo a cota. Um plano com SCAN indica que o banco pode percorrer todas as linhas da tabela. Um resultado com SEARCH ... USING INDEX mostra que o planejador conseguiu ir diretamente aos registros compatíveis por meio de um índice.
Teste primeiro em desenvolvimento ou em uma cópia segura do banco. O plano depende do esquema, dos índices e das condições reais da consulta; copiar um índice genérico sem verificar a coluna filtrada pode aumentar o trabalho de escrita sem melhorar a leitura.
- Execute: EXPLAIN QUERY PLAN SELECT * FROM orders WHERE customer_id = ?
- Se aparecer SCAN, verifique se customer_id participa com frequência do WHERE ou de um JOIN.
- Crie um índice testado, por exemplo: CREATE INDEX IF NOT EXISTS idx_orders_customer_id ON orders(customer_id)
- Execute PRAGMA optimize e repita o EXPLAIN QUERY PLAN.
- Confirme no meta da consulta que o número de linhas lidas realmente caiu.
Como reduzir linhas lidas
Índices em colunas usadas repetidamente em WHERE e JOIN costumam ser a correção mais importante. Paginação, seleção apenas das colunas necessárias, cache com invalidação adequada e redução de polling também ajudam, mas não substituem a análise do plano de execução.
Evite assumir que LIMIT reduz a varredura. Sem um índice que satisfaça o filtro e a ordenação, o banco ainda pode examinar muitas linhas antes de encontrar os resultados. Buscas como LIKE '%termo%' normalmente não aproveitam um índice B-tree comum e merecem outra estratégia quando executadas com frequência.
Como reduzir linhas gravadas sem exagerar nos índices
Revise atualizações redundantes, sincronizações que regravam valores iguais, tarefas agendadas muito frequentes e importações sem divisão em lotes. Prefira operações idempotentes e registre quantas linhas cada rotina realmente altera.
Todo índice precisa ser atualizado quando a tabela recebe INSERT, UPDATE ou DELETE. Portanto, criar muitos índices pode diminuir leituras e aumentar o custo das escritas. Mantenha apenas os índices que atendem consultas reais e valide o efeito dos dois lados nas métricas.
O que fazer quando a aplicação já está bloqueada
Desative temporariamente jobs não essenciais, polling e agentes que continuam consultando o banco. Exiba uma resposta controlada no aplicativo e preserve os logs necessários para encontrar a consulta responsável. A Cloudflare informa que o acesso volta quando a cota é reiniciada à meia-noite UTC; no horário de Brasília, que usa UTC−3 nesta data, isso corresponde a 21h.
Se a aplicação não pode esperar e o consumo é legítimo mesmo após otimização, avalie o plano pago. Não apague dados nem desative validações de segurança: a própria Cloudflare esclarece que o conteúdo armazenado permanece intacto durante o bloqueio por cota.
Por que retry e backoff não resolvem a cota diária
Backoff exponencial com jitter é adequado para falhas transitórias específicas, como perda de conexão ou reinício do armazenamento. O D1 também tenta novamente consultas somente de leitura até duas vezes quando detecta um erro recuperável.
A cota diária esgotada não muda enquanto o limite não reinicia ou o plano não é alterado. Repetir a consulta nesse intervalo apenas gera mais falhas e pode ampliar o impacto sobre o Worker. Além disso, uma nova tentativa manual só é segura quando a operação é idempotente ou quando a aplicação consegue confirmar que a escrita anterior não foi aplicada.
É limite da conta ou indisponibilidade da Cloudflare?
A mensagem explícita de daily row read limit ou daily row write limit aponta para a conta, não para uma queda global. Se o texto for de rede, erro interno ou sobrecarga, se vários produtos da Cloudflare apresentarem falhas ao mesmo tempo, ou se a consulta continuar falhando depois do reinício da cota, consulte a página oficial de status e teste o endpoint de fora da sua rede.
Uma ferramenta externa confirma DNS, HTTPS e resposta HTTP, mas não enxerga as métricas privadas do D1 nem o plano da conta. Use o diagnóstico público para separar uma falha de acesso de um bloqueio interno e confirme a causa no painel e nos logs.
Limites deste diagnóstico
Este guia foi verificado em 6 de setembro de 2026 e trata da aplicação dos limites diários de linhas no plano Workers Free. Valores de cota, preços, planos e comportamento do produto podem mudar. Consulte a página oficial de limites antes de tomar uma decisão de capacidade.
Métricas agregadas ajudam a localizar o período e o banco, mas não substituem instrumentação por consulta. Um índice também não é uma correção universal: filtros pouco seletivos, ordenações diferentes, condições compostas e padrões de escrita exigem testes com o esquema real.
Próxima ação útil
Abra agora a aba Metrics do banco que falhou, compare rowsRead e rowsWritten no intervalo do alerta e selecione a consulta com maior impacto. Use EXPLAIN QUERY PLAN, adicione apenas um índice justificado pelo acesso real e confirme a redução no objeto meta. Depois configure alertas internos antes da cota, para agir antes que o aplicativo pare de consultar o D1.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- D1 enforces free tier daily query limitsCloudflare Changelog
- Debug D1Cloudflare Docs
- Metrics and analyticsCloudflare Docs
- Use indexesCloudflare Docs
- Retry queriesCloudflare Docs
- D1 limitsCloudflare Docs