A visão de um engenheiro de campo sobre a mudança de preços em setembro de 2026 — e o que realmente fazer a respeito.

Se você construiu algo no Firebase nos últimos anos, Remote Config provavelmente era o único produto que nunca precisou pensar. Bandeiras de recurso, verificação de versão forçada, parâmetros de teste A/B — tudo gratuito, ilimitado e para sempre. Isso muda em 1º de setembro de 2026.

Eu construo aplicativos móveis offline-first para departamentos do governo de Tamil Nadu — apps usados por mais de 50.000 oficiais de campo em todos os 38 distritos, verificando diariamente das aldeias com conectividade fraca. Remote Config silenciosamente alimenta verificações de atualização forçada e bandeiras de lançamento em vários desses aplicativos. Então quando vi essa mudança de preços, não apenas li o anúncio — fiz a matemática contra tráfego real de produção. Aqui está o que descobri, e o que penso que cada engenheiro móvel dependendo do Remote Config deve verificar antes de setembro.

O Que Está Realmente Mudando

Remote Config está se movendo de “ilimitado e gratuito” para um modelo baseado em uso com uma camada gratuita:

• Plano Spark (gratuito): até 100.000 solicitações de busca por dia, por projeto, sem custo.
• Plano Blaze (pague conforme usar): as primeiras 100.000 buscas diárias ainda são gratuitas. Além disso, é $0,06 por 10.000 solicitações (aproximadamente $0,000006/solicitação) até 10 milhões de solicitações/dia, caindo para $0,01 por 10.000 solicitações além disso.
• Todos os recursos — Personalização, Lançamentos, Integração de teste A/B — permanecem incluídos em ambos os planos. Nada está sendo bloqueado por recurso; isso é puramente um limite de volume nas solicitações de busca.

Importante, se você está em Spark e cruzar a linha de 100.000/dia, não é cortado imediatamente. Há um período de graça de 30 dias antes que o rateio entre em vigor — tempo suficiente para reagir, mas não tempo suficiente para ignorá-lo.

A Matemática da Busca Que Ninguém Está Fazendo

Aqui está a parte que importa mais do que o título: uma solicitação de busca só é disparada quando seu app realmente chama a rede (fetch() / fetchAndActivate(), ou um pull de modelo via REST/Admin SDK). Ler um valor já armazenado em cache no dispositivo — activate(), getString() — não custa nada. Então a variável real não é o número de usuários. É:

daily fetches ≈ daily active users × fetches per session × sessions per day

O próprio Firebase define um intervalo mínimo de 12 horas. Se seu aplicativo respeita essa configuração padrão e o usuário abre o app duas vezes ao dia, isso resulta em aproximadamente 2 fetches por usuário por dia. Faça os cálculos para um app com 50.000 usuários ativos diariamente (DAU) e você chegará a quase exatamente 100.000 fetches — no limite do gratuito, antes de adicionar um segundo aplicativo, um intervalo de fetch mais curto ou um dia de lançamento movimentado.

Essa é a armadilha. A maioria das equipes define setMinimumFetchIntervalInSeconds baixo durante o desenvolvimento (para testar mudanças imediatamente) e simplesmente esquece de aumentá-lo antes do lançamento. Em um pequeno app, ninguém percebe. Em um aplicativo governamental com milhares de usuários diariamente, essa configuração residual de desenvolvimento se torna uma conta real — ou pior, atualizações de configuração limitadas para usuários que você não pode permitir ficar em um sinal forçado.

O Que Verificar Antes de Setembro

1. Audite seu intervalo de fetch em builds de produção. Se for menor que algumas horas, você provavelmente está fazendo fetches excessivamente para nenhum benefício — a maioria das flags remotas não precisa ser atualizada mais rápido do que uma vez a cada 12–24 horas.
2. Verifique bugs de fetch em cada tela. Uma chamada fetchAndActivate() solta em um componente que re-renderiza frequentemente (barra de abas, ouvinte de navegação) multiplicará silenciosamente seu contador diário.
3. Olhe o volume de fetch por projeto, não por app. Se você roda vários apps sob um único projeto Firebase, eles compartilham a mesma cota de 100.000/dia.
4. Defina um alerta de cobrança no console Firebase/Cloud antes que você seja forçado a fazê-lo.

Para a maioria dos apps, apenas os passos 1–2 são suficientes para permanecer confortavelmente dentro da camada gratuita — sem necessidade de migração.

Se Você Precisa Realmente de uma Alternativa

Se seu padrão de uso é intrinsecamente de alta frequência (personalização em tempo real, configuração por solicitação, não apenas flags diários), permanecer no Remote Config e pagar a tarifa marginal ainda pode ser mais barato do que o tempo de engenharia para migrar. Mas se você quiser eliminar totalmente o risco de cobrança:

OpçãoCustoTrade-offFirestore (se já em sua pilha)Gratuito até 50K leituras/dia/projetoVocê está recriando a lógica de fetch de configuração, mas é um padrão que a maioria das equipes Firebase já conheceConfigCatGratuito para o nível gratuitoConstruído especificamente para flags/config, SDK drop-in, sem auto-hospedagemUnleash (auto-hospedado)Gratuito, código abertoNunca há cobrança por solicitação, mas você é responsável pelas operaçõesFlagsmith (auto-hospedado)Gratuito, código abertoSemelhante ao Unleash, interface mais bonita, ainda auto-hospedado

A Verdadeira Lição

Isso não é realmente uma história sobre a Firebase ficar gananciosa. Um teto de 100.000 consultas gratuitas por dia é generoso para a grande maioria dos aplicativos — apenas prejudica equipes que ou escalaram além do orçamento inicial, ou nunca revisaram as configurações feitas durante o desenvolvimento. A lição para qualquer engenheiro lançando algo com uso real e sustentado diário: trate cada padrão 'gratuito para sempre' de SDK como uma decisão que eventualmente terá que ser justificada novamente em escala, não como um fato configurado uma vez e esquecido.

Se você está construindo para escala — aplicativos governamentais, ou qualquer coisa com uma base de usuários diariamente ativos em crescimento — este é um bom momento para voltar e realmente ler as documentações sobre o limite de consultas para cada SDK de terceiros que depende, não apenas Remote Config.