Cloudflare D1: quando o plano grátis bloqueia consultas

Desde 1º de setembro de 2026, manter o Cloudflare D1 Free em produção passou a ser uma decisão de disponibilidade. Quando uma conta consome 5 milhões de linhas lidas ou 100,000 linhas gravadas em um dia, as consultas ao D1 podem parar até a meia-noite UTC.

Cloudflare D1: mudou o modo de falha, não a cota

As franquias gratuitas já existiam. O que mudou foi o que acontece quando elas acabam.

No Workers Free, ultrapassar qualquer uma das franquias diárias agora faz o D1 rejeitar consultas tanto pela Workers Binding API quanto pela REST API. A Cloudflare documenta mensagens diferentes para os limites de leitura e gravação e informa que as consultas voltam a funcionar quando a franquia é renovada às 00:00 UTC. Os dados armazenados continuam intactos. Ainda assim, o aplicativo pode ficar sem conseguir lê-los ou alterá-los.

Essa diferença resume toda a história. Um número que antes apenas indicava consumo virou um limite rígido de disponibilidade.

A Cloudflare envia um e-mail quando o limite diário é atingido. A mensagem explica por que o incidente está acontecendo, mas chega depois que o banco de dados já ficou indisponível. Uma equipe de produção precisa de um orçamento e de um alerta antecipado, não apenas de uma explicação após a falha. O changelog do D1 de 1º de setembro traz o comportamento exato da falha e as mensagens de erro.

O Workers Paid não é afetado por essa interrupção diária. Um protótipo que permanece com folga abaixo das duas franquias talvez não precise migrar hoje. Já um produto em operação que depende do D1 precisa tratar o plano Free como qualquer outro recurso sujeito a uma interrupção ao atingir o limite.

No Cloudflare D1, o que conta são as linhas varridas

A franquia de leitura não corresponde a 5 milhões de chamadas de API nem a 5 milhões de registros retornados. Ela corresponde a 5 milhões de linhas varridas pelo banco de dados ao responder às consultas.

Imagine que um filtro retorne apenas um cliente, mas não tenha um índice útil. O D1 pode precisar varrer uma tabela de 5,000 linhas para encontrar esse registro. Execute essa consulta 1,000 vezes e todas as 5 milhões de leituras diárias de linhas terão sido consumidas. O resultado parecia pequeno; o trabalho por trás dele não era.

As gravações são mais diretas. Um INSERT, UPDATE ou DELETE contabiliza as linhas alteradas. Inserir 10 linhas conta como 10 linhas gravadas. Operações de esquema como CREATE, ALTER e DROP também podem consumir uma combinação de leituras e gravações.

O tamanho da linha não muda essa medição. Uma linha de 1 KB e outra de 100 KB contam, cada uma, como uma linha. É o formato da consulta que determina o volume de leitura.

Um índice permite que o D1 vá direto aos registros relevantes em vez de varrer a tabela. Em geral, isso troca um pequeno volume adicional de gravações por uma redução muito maior nas leituras. Ao gravar em uma coluna coberta por um índice, o D1 escreve a linha da tabela e pelo menos uma entrada no índice. Por isso, o caminho certo é indexar as colunas usadas com frequência em filtros e junções — não todas as colunas disponíveis.

O guia de índices da Cloudflare oferece um teste simples. Adicione EXPLAIN QUERY PLAN antes da consulta cara. Um plano com SCAN está lendo a tabela. Um plano com SEARCH ... USING INDEX está usando um índice. Depois de criar um índice, execute PRAGMA optimize para que o planejador de consultas trabalhe com estatísticas atualizadas.

A conta para o negócio mudou

O Workers Free continua custando $0. O que mudou foi o risco: o gasto máximo com o banco de dados continua em zero, mas agora ele pode deixar de atender o aplicativo durante o restante do dia UTC.

O Workers Paid começa em $5 por conta ao mês. No lugar da interrupção diária rígida, ele oferece uma franquia mensal e cobrança pelo uso excedente.

O salto do Free para o Paid é maior do que parece. Trinta dias no teto de leitura do Free somariam 150 milhões de linhas, apenas 0.6% das 25 bilhões de leituras incluídas no Paid. Trinta dias no teto de gravação do Free somariam 3 milhões de linhas, ou 6% das 50 milhões de gravações incluídas.

Para muitos aplicativos pequenos, portanto, a primeira decisão de pagar não tem relação com uso excedente. É uma decisão de disponibilidade que custa $5. As solicitações do Workers, a CPU, o armazenamento do D1 acima de 5 GB e qualquer outro produto da Cloudflare continuam com suas próprias métricas de cobrança. Assim, $5 é o piso, não uma promessa de que a conta inteira custará exatamente $5. A análise mais ampla de preços da Cloudflare mostra onde essas cobranças por conta e por produto se separam.

O D1 não cobra por transferência de dados nem por throughput. Isso não ameniza a falha no Free; significa apenas que o tráfego de saída não entra nos números dessa decisão.

Quatro equipes, quatro decisões práticas

Quem toca sozinho um SaaS em produção

Se o login, o status de cobrança ou o painel do cliente consulta o D1, o plano Free agora traz risco de indisponibilidade em produção. Primeiro, identifique o dia normal de maior movimento e corrija qualquer varredura completa. Se o aplicativo continuar chegando perto do teto, o mínimo de $5 custa menos do que se planejar para um número incerto de horas sem acesso ao banco de dados.

O ganho não é uma capacidade abstrata maior. É eliminar a meia-noite UTC do plano de recuperação de incidentes.

Uma agência com vários bancos de dados na mesma conta

Os limites são definidos por conta. Uma agência deve fazer o inventário de todos os bancos D1 vinculados àquela conta Cloudflare, em vez de analisar a propriedade de um único cliente e concluir que a conta está segura.

Use as métricas de cada banco para localizar o projeto que mais consome recursos e, depois, some os totais antes de definir o orçamento da conta. O resultado é um número compartilhado que a operação pode assumir. A varredura ineficiente de um projeto não deve surgir como uma interrupção misteriosa em outro lugar da mesma conta.

Engenharia de backend investigando leituras caras

O objetivo é identificar padrões de consulta, não apagar dados ao acaso. O D1 retorna rows_read e rows_written dentro do objeto meta de cada consulta. Esses contadores mostram o custo exato de uma execução.

A Cloudflare também disponibiliza insights de consultas pelo Wrangler e pela GraphQL Analytics API. Ordene por leituras para encontrar as varreduras repetidas, examine o plano, adicione o índice específico necessário e meça novamente. A mesma mudança reduz o uso da cota e, em geral, também a latência.

Liderança de operações durante importações ou sincronizações

Uma sincronização em massa pode consumir 100,000 gravações antes que o tráfego dos clientes tenha a chance de usar o banco de dados. Distribua um trabalho não urgente entre as janelas de renovação ou migre a conta para o Paid antes de uma importação em produção.

Não planeje fazer a limpeza depois de atingir o teto de gravações. DELETE também é uma operação de escrita; portanto, a mesma franquia esgotada pode bloquear a consulta de limpeza até a renovação. O benefício é manter as gravações do ambiente de produção disponíveis enquanto o processamento em lote é executado.

Defina o orçamento do limite antes que o alerta chegue

Esta é uma primeira política viável. Trata-se de uma regra operacional, não de uma exigência da Cloudflare: limite o orçamento de produção a 80% da franquia publicada do Free. Isso cria um teto operacional diário de 4 milhões de leituras e 80,000 gravações, deixando 1 milhão de leituras e 20,000 gravações como margem para picos e atrasos na medição.

1. 1

   Meça um dia real

   Abra a Cloudflare, acesse D1, selecione cada banco de dados e abra Metrics. A visualização padrão mostra as últimas 24 horas. Consulte um histórico suficiente para enxergar dias úteis comuns, lançamentos, importações e picos de tráfego. O D1 mantém essas métricas por 31 dias.

2. 2

   Encontre a consulta que consome as linhas

   Durante os testes dos fluxos importantes, use os valores meta.rows_read e meta.rows_written de cada consulta. Use os insights de consultas para ordenar as instruções mais frequentes ou caras. Execute EXPLAIN QUERY PLAN na pior consulta de leitura e corrija uma varredura completa antes de considerar a migração de plano como a única resposta.

3. 3

   Alerte antes do limite rígido

   Use a GraphQL Analytics API, que consulta os mesmos conjuntos de dados do painel, para fazer uma verificação programada da conta. Avise a pessoa responsável ao atingir 4 milhões de leituras ou 80,000 gravações. O e-mail da Cloudflare no limite total ainda serve como confirmação do incidente, mas não deve ser o primeiro sinal em produção.

4. 4

   Defina agora o comportamento em caso de falha

   Decida o que o Worker retornará se o D1 gerar um erro de limite. Uma leitura em cache pode continuar útil se não executar outra consulta ao D1. Um fluxo de gravação precisa de uma resposta clara de indisponibilidade ou de uma fila projetada separadamente. Não crie um loop de novas tentativas para uma cota que só será renovada à meia-noite UTC ou após um upgrade.

A documentação de métricas do D1 identifica rowsRead e rowsWritten como os campos da GraphQL e confirma que o painel usa os mesmos dados analíticos. Assim, uma equipe pequena pode começar hoje por um caminho manual e adotar um caminho automatizado quando o banco de dados se tornar importante o bastante para acionar alguém.

Os limites reais da solução

Um índice tem custo. Ele ocupa armazenamento e acrescenta gravações quando os valores indexados mudam. Crie os índices que eliminam varreduras caras e, depois, meça o novo equilíbrio. Uma conta que já esteja perto do limite de 100,000 gravações pode piorar esse equilíbrio se indexar tudo sem critério.

O Paid também não é ilimitado. O plano inclui 25 bilhões de leituras e 50 milhões de gravações por mês; depois, cobra o excedente pelas tarifas publicadas. O upgrade remove a interrupção diária do Free, normalmente em poucos minutos, mas não elimina a necessidade de monitorar consultas ruins nem de estimar o restante da fatura do Workers. A página atual de Cloudflare D1 pricing é a referência de valores que deve ficar no runbook.

Há um detalhe no histórico das fontes que vale conhecer. Uma nota de versão do D1 de janeiro de 2025 dizia que a aplicação dos limites começaria em 10 de fevereiro de 2025. O changelog mais recente e específico sobre o evento informa que ela começa em 1º de setembro de 2026. A página mais nova é usada aqui como referência principal porque descreve diretamente a implementação atual. Isso explica por que um resultado de busca mais antigo pode mostrar outra data.

Por fim, “os dados armazenados não são afetados” é uma afirmação mais restrita do que “o produto está funcionando”. Os dados podem estar seguros enquanto todas as rotas que dependem deles retornam erro. A disponibilidade é a consequência para o negócio.

O que fazer na segunda-feira

Tome uma providência ainda nesta semana se um aplicativo voltado para clientes roda no Workers Free e consulta o D1 durante as solicitações. Primeiro, meça; depois, corrija as varreduras evidentes, configure o alerta em 4 milhões de leituras e 80,000 gravações e pré-autorize a migração para o Paid, cujo mínimo é $5.

Espere se for um protótipo descartável, se o histórico de 31 dias permanecer bem abaixo do orçamento operacional e se um dia de falha nas consultas não afetar clientes nem receita. Mesmo assim, mantenha o alerta: tanto o tráfego quanto o tamanho das tabelas alteram o cálculo das leituras.

Essa interrupção diária específica não afeta contas que já estão no Workers Paid nem aplicativos que não consultam o D1.

A ação para segunda-feira é simples: abra a guia Metrics do D1 em cada banco, anote o dia de maior leitura e gravação da conta, identifique a consulta responsável pela maior varredura e dê a uma pessoa a autoridade para fazer o upgrade. Se, mesmo após corrigir a consulta, um pico normal ainda ultrapassar 4 milhões de leituras ou 80,000 gravações, migre a conta para o Workers Paid naquele dia.

Se quiser receber a próxima mudança de plataforma já convertida em uma decisão operacional, assine a newsletter.