TL;DR O modelo de preços do BigQuery mudou de forma estrutural em julho de 2023. O flat-rate foi descontinuado e substituído por três níveis de Editions com autoscaling de slots. Ou seja: a maioria dos guias de custo escritos antes de 2023 está desatualizada, e boa parte dos projetos de otimização planejados como ações pontuais é insuficiente para 2026. Este artigo mostra como o pricing do BigQuery realmente funciona hoje, quais táticas mexem na fatura e como identificar problemas de custo antes que eles cheguem no invoice.
A maioria dos problemas de custo no BigQuery aparece da pior maneira possível: um item inesperado na fatura do mês passado, o líder do time de dados encaminhando um screenshot de um pico, uma pergunta do financeiro que ninguém consegue responder rápido. Quando a conversa começa, a query que causou tudo já rodou faz duas semanas.
Esse gap de descoberta não é falha de ferramenta. É estrutural. O BigQuery cobra depois do consumo, a otimização disputa espaço com o roadmap, e o modelo de preços mudou tanto desde que a maioria dos guias foi escrita que boa parte das recomendações padrão simplesmente não se aplica mais. Engenheiros que seguem orientações baseadas em slots flat-rate ou em incrementos de autoscaling de 50 slots estão ajustando um modelo que nem existe mais.
Este guia mostra como é, na prática, a otimização de custos do BigQuery em 2026: o modelo de preços atual, as táticas que reduzem gastos sem degradar performance e a camada de observabilidade que viabiliza a melhoria contínua.
Por que otimizar custos no BigQuery é diferente em 2026
A informação mais importante sobre o pricing do BigQuery em 2026 é que o flat-rate acabou. O Google descontinuou a compra de slots flat-rate e os Flex Slots em 05/07/2023, substituindo-os por um modelo de três níveis chamado Editions: Standard, Enterprise e Enterprise Plus. O pricing on-demand continua disponível, mas o lado da capacidade do BigQuery agora funciona de um jeito diferente do que a maior parte da documentação descreve.
O autoscaling de slots é o modelo padrão de capacidade no Editions. Em vez de comprar um bloco fixo de slots por mês, você configura uma baseline (o piso que fica sempre reservado) e um máximo (o teto que o autoscaler pode atingir). O BigQuery escala entre esses limites conforme a demanda das queries, cobrando por slot-hora em vez de cobrar contra um bloco contratado. Consequência prática: a exposição de custo escala com o uso, não com uma compra predeterminada, o que transforma a otimização numa atividade contínua, e não numa decisão pontual de provisionamento.
Essa mudança importa para a forma como os times de engenharia devem encarar o trabalho de custos. E amplia o escopo do que precisa ser monitorado. Otimizar custos do BigQuery em 2026 significa contabilizar serviços auxiliares junto com o compute principal: o Cloud Composer v3 (especificamente a versão 3, que trouxe um novo modelo de billing) e o Dataplex geram cobranças que aparecem em SKUs adjacentes ao BigQuery e somam ao custo total de uma plataforma de dados. Times que estão planejando uma iniciativa de custos deveriam puxar os dados de billing desses serviços junto com o compute do BigQuery desde o início, em vez de tratar como uma faxina à parte.
Particionar uma tabela continua ajudando, mas o cálculo de economia é diferente quando você está em autoscaling de slots em vez de flat-rate. Escalonar workloads para ficar abaixo de um limite de commitment de slot era a jogada certa em 2022; em 2026, o objetivo é reduzir as slot-horas que seus workloads consomem em primeiro lugar e dimensionar baseline e teto para o padrão real de uso. Otimização é tuning contínuo, não um projeto que você encerra.
Como o pricing do BigQuery realmente funciona
O BigQuery cobra por duas coisas de forma independente: compute e storage. O compute é onde a maior parte da atenção de otimização deve estar, porque é onde os custos escalam de forma imprevisível.
Pricing on-demand
O on-demand cobra por tebibyte escaneado a US$ 6,25 por TiB, com o primeiro 1 TiB por mês gratuito por projeto. Você não compra slots diretamente; o Google aloca até 2.000 slots compartilhados por projeto em segundo plano. O on-demand funciona bem para times com volume de queries irregular ou leve, ambientes de desenvolvimento e teste e análises ad-hoc, em que os padrões de query são imprevisíveis. O risco é o custo de scan: uma query mal escrita contra uma tabela grande e sem particionamento pode gerar uma cobrança considerável em um único job.
Pricing por slot do Editions
O Editions cobra por slot-hora: o número de slots disponibilizados pela sua reserva multiplicado pelo tempo em que ficam ativos. Na região US, as taxas pay-as-you-go são US$ 0,04 por slot-hora no Standard, US$ 0,06 no Enterprise e US$ 0,10 no Enterprise Plus. Enterprise e Enterprise Plus também oferecem commitments de slot de 1 e 3 anos com desconto. Separadamente desses commitments de capacidade, o Google ainda oferece Committed Use Discounts (CUDs) baseados em gasto, que aplicam 10% de desconto para um compromisso de 1 ano e 20% para 3 anos sobre todo o uso PAYG elegível do BigQuery em uma região.
O autoscaling no Editions escala em incrementos de 50 slots (não 100, como dizia a documentação mais antiga), com uma janela mínima de billing padrão de 60 segundos por evento de autoscaling. Esse piso de 60 segundos é a janela de scale-down do autoscaler, não uma regra por query. Uma query de pico curto que dispara o autoscaling continua gerando pelo menos um minuto de cobrança sobre esses slots adicionais por padrão. O Google adicionou um recurso opt-in chamado fluid scaling, agora em disponibilidade geral, que substitui o mínimo de 60 segundos por billing real por segundo no nível da reserva. Times com queries curtas, de alta frequência ou variáveis devem avaliar se habilitar fluid scaling reduz o custo efetivo de slot-hora.
A matemática de break-even entre on-demand e Editions fica mais útil quando ancorada no Enterprise Edition, que é a comparação mais relevante para a maioria dos times de produção: o Standard Edition tem teto de 1.600 slots por reserva e não inclui CMEK, BI Engine nem commitments multianuais, recursos que costumam ser deal-breakers ao migrar workloads previsíveis do on-demand. A US$ 0,06 por slot-hora, 100 slots do Enterprise Edition rodando continuamente por um mês custam cerca de US$ 4.380, equivalente a escanear aproximadamente 700 TiB no on-demand a US$ 6,25 por TiB. Se seu time consistentemente escaneia menos do que isso com timing imprevisível, o on-demand provavelmente sai mais barato. Se você escaneia mais, ou se seus workloads se concentram em janelas previsíveis, o pricing por slot do Editions deve vencer. A única forma confiável de calcular seu break-even real é consultar o INFORMATION_SCHEMA.JOBS para obter o total de slot-milliseconds dos últimos 30 a 90 dias e converter para slot-horas.
Pricing de storage
O BigQuery oferece dois modelos de billing de storage no nível do dataset: lógico e físico. O storage lógico, que é o padrão, cobra sobre bytes não comprimidos. O storage físico cobra sobre bytes comprimidos e, como o BigQuery comprime os dados antes de cobrar, a taxa bruta por GiB é menor. O trade-off é que o storage físico agora exige pagar por time travel e sete dias de fail-safe storage à taxa de armazenamento físico ativo, custos que não se aplicam no billing lógico. Para datasets com altas taxas de compressão, o modelo físico ainda vence no custo total; para outros, o overhead de time travel e fail-safe pode inverter a conta. Use a query de comparação de billing de storage da biblioteca de queries de otimização do BigQuery da DoiT (github.com/doitintl/bigquery-optimization-queries) para calcular a recomendação líquida para cada dataset antes de mudar. O storage ativo e o long-term storage (tabelas ou partições não modificadas há 90 dias) têm taxas diferentes em ambos os modelos, com o long-term storage saindo por cerca de metade da taxa ativa. Tabelas sem uso e partições antigas que nunca migram para o status long-term por causa de escritas incidentais representam um custo oculto comum.
Atribuição do modelo de pricing
Um detalhe fácil de passar batido: o modelo de pricing é escolhido por atribuição de reserva, não por organização. Projetos ou pastas diferentes dentro da mesma organização do Google Cloud podem rodar em modelos distintos ao mesmo tempo. Um projeto de desenvolvimento pode ficar no on-demand enquanto os workloads de produção rodam em slots do Enterprise Edition. Essa flexibilidade por projeto significa que você não precisa tomar uma decisão única tudo-ou-nada para a organização inteira.
ModeloUnidade de billingTaxa pay-as-you-go USMelhor encaixeOn-demandTiB escaneado$6,25 / TiBWorkloads irregulares, leves ou imprevisíveisStandard EditionSlot-hora$0,04 / slot-hTimes de analytics com volume consistente e moderado; sem necessidade de commitmentEnterprise EditionSlot-hora$0,06 / slot-hWorkloads de produção que exigem segurança, governança ou inclusão de BI EngineEnterprise PlusSlot-hora$0,10 / slot-hWorkloads mission-critical com DR cross-region ou requisitos de compliance
Táticas de otimização de custos no BigQuery que mexem na fatura
As táticas abaixo reduzem o que o BigQuery cobra, esteja você no on-demand ou no Editions. No on-demand, menos bytes escaneados significam fatura menor diretamente. No Editions, execução mais eficiente das queries significa menos slot-horas consumidas, o que reduz o custo do teto de autoscaling e do commitment de baseline.
Escolha o modelo de billing de storage certo
O billing de storage físico é uma das alavancas de custo de maior impacto no BigQuery e uma das mais ignoradas. O BigQuery oferece dois modelos de billing de storage no nível do dataset: lógico (o padrão legado, cobrado sobre bytes não comprimidos) e físico (cobrado sobre bytes comprimidos). O storage físico custa cerca do dobro da taxa lógica por GiB, mas, como o BigQuery comprime os dados antes de cobrar, o custo efetivo é menor para a maioria dos workloads.
A economia depende inteiramente da sua taxa de compressão. O BigQuery usa um algoritmo de compressão genérico, e não um algoritmo por coluna otimizado para tipos específicos de dados. Workloads com dados de alta entropia, como logs, event streams ou registros pesados em texto, costumam comprimir em proporções de 10:1 ou mais com esse algoritmo, deixando o storage físico bem mais barato. Workloads dominados por tipos numéricos de largura fixa, como integers, doubles e floats, têm pouca redundância estrutural para um algoritmo genérico explorar, então comprimem mal, e o billing físico pode acabar custando mais do que o lógico. Rode a query de comparação de billing de storage no seu projeto antes de converter qualquer dataset: ela mostra o custo atual, o custo projetado no outro modelo e uma recomendação para cada dataset. O modelo é definido por dataset, não por projeto, então dá para trocar datasets de alto valor individualmente sem mexer no resto.
Para dados que você é legalmente obrigado a reter, mas raramente ou nunca consulta, considere exportar para Google Cloud Storage Coldline ou Archive. Um dataset de retenção HIPAA de sete anos parado no BigQuery gera cobranças de storage ativo ou long-term indefinidamente. Os mesmos dados em um bucket GCS Archive custam uma fração disso, continuam consultáveis via tabelas externas do BigQuery quando necessário, e são deletados automaticamente quando a janela de retenção expira, se você configurar regras de lifecycle.
Particione tabelas para escanear menos dados
O particionamento divide uma tabela grande em segmentos menores, geralmente por data ou por uma coluna de alta cardinalidade, para que as queries possam pular as partições de que não precisam. A técnica só é eficaz quando as queries incluem um filtro qualificador na coluna de partição. Uma query contra uma tabela particionada que não filtra pela chave de partição escaneia a tabela inteira, como se o particionamento não existisse.
A prioridade prática: particionar tabelas que carregam uma dimensão temporal e que seus dashboards ou jobs agendados consultam com filtros de data. Consultar INFORMATION_SCHEMA.JOBS_BY_PROJECT filtrando por total_bytes_processed revela tabelas com jobs recorrentes sem filtros de partição. Esses são o caminho mais rápido para reduzir scan.
Faça clustering das tabelas para um pruning mais granular
O clustering organiza os dados de uma tabela em blocos pelos valores de uma ou mais colunas. Queries que filtram por essas colunas pulam os blocos que não correspondem, reduzindo bytes escaneados além do que só o particionamento consegue. O clustering funciona melhor em colunas de alta cardinalidade que aparecem com frequência em cláusulas WHERE ou condições de JOIN, e a ordem das colunas na definição do cluster deve refletir a ordem dos filtros das queries.
Particionamento e clustering podem ser aplicados juntos. A combinação faz sentido para tabelas grandes consultadas tanto por uma dimensão temporal quanto por uma coluna de filtro secundária, como um ID de tenant ou tipo de evento. O trade-off: estratégias combinadas aumentam o overhead de metadados da tabela, e os benefícios do clustering diminuem se as queries não filtrarem consistentemente pelas mesmas colunas, na ordem definida.
Filtre cedo e selecione de forma enxuta
O BigQuery cobra sobre bytes escaneados antes de os filtros rodarem, o que significa que um SELECT * contra uma tabela larga cobra por todas as colunas, independentemente de quais o output realmente usa. Selecionar só as colunas necessárias e aplicar filtros de partição e cluster cedo na query reduz o volume de scan diretamente. Subqueries que referenciam tabelas largas, mesmo quando a query externa projeta apenas algumas colunas, puxam o custo total de scan para a fatura.
O parâmetro maximum_bytes_billed por query permite definir um teto rígido para o volume de scan de uma única query. Qualquer query que ultrapassaria o limite falha rapidamente em vez de completar e gerar uma cobrança grande. Essa configuração funciona como guardrail de custo no desenvolvimento e como rede de segurança em produção para jobs em que uma query descontrolada sairia cara.
Ajuste baselines e tetos de slot do autoscaling
No Editions, você controla dois parâmetros de slot por reserva: a baseline (slots sempre disponíveis) e o máximo (o teto que o autoscaler pode atingir). O autoscaling adiciona capacidade em incrementos de 50 slots quando a demanda excede a baseline, com uma janela de scale-down de 60 segundos antes de liberar esses slots por padrão. Um job que aciona autoscaling por um único segundo gera um minuto inteiro de billing sobre esses 50 slots adicionais no autoscaling padrão. Se você optar por fluid scaling no nível da reserva, o BigQuery passa a cobrar por segundo de verdade, sem duração mínima, o que pode reduzir custos em até 34% para workloads com padrões de query curtos ou variáveis, segundo o Google. O tamanho do incremento de 50 slots não muda no fluid scaling.
Definir o máximo alto demais faz com que jobs de pico curto possam escalar para faixas caras sem necessidade. Definir a baseline baixa demais faz com que a maior parte dos workloads rode em capacidade autoescalada, que custa mais por slot-hora do que os slots de baseline contratados quando há commitments de Enterprise ou Enterprise Plus em jogo. O alvo da otimização é uma baseline que cubra o piso de workload em regime permanente e um teto máximo dimensionado para absorver picos legítimos sem deixar margem para jobs descontrolados.
Consulte o INFORMATION_SCHEMA.JOBS dos últimos 60 dias para mapear o uso real de slots concorrentes por hora do dia. Essa distribuição diz onde definir a baseline e onde o máximo deve limitar. Para um passo a passo detalhado do caminho de migração a partir do on-demand, o guia de migração em cinco etapas da DoiT cobre o setup completo da reserva.
Um padrão operacional que reduz custos em workloads previsíveis: redimensionar sua reserva dinamicamente em torno de janelas conhecidas de ETL. Suba a baseline antes de um job pesado de transformação noturna e baixe de novo quando o job terminar. Você evita segurar slots caros nas horas ociosas dos dois lados do job. A mesma abordagem funciona ao contrário para times que precisam de folga em horário comercial, mas rodam workloads mínimos durante a madrugada.
Combine CUDs baseados em gasto com a sua escolha de modelo de pricing
Uma vez que você se comprometeu com Editions em um projeto, há um segundo mecanismo de desconto que vale avaliar: os Committed Use Discounts baseados em gasto. Eles são separados dos commitments de capacidade de slot. Em vez de se comprometer com uma quantidade fixa de slots, você se compromete com um valor mínimo de gasto por hora com o BigQuery em uma região específica, e o Google aplica desconto a todo o uso PAYG elegível coberto por esse compromisso.
Taxas atuais de desconto: 10% para 1 ano e 20% para 3 anos. O desconto se aplica automaticamente a todos os tipos de compute PAYG do BigQuery na região contratada, sem alocação manual de slots. O uso acima do valor horário contratado é cobrado à taxa PAYG padrão; o uso abaixo dele ainda gera a cobrança do valor contratado. O commitment não pode ser cancelado, então dimensione com base no seu gasto horário mínimo esperado, e não na média, para evitar pagar por capacidade contratada que fica sem uso em períodos mais lentos.
Um risco operacional: os commitments de slot no Editions renovam automaticamente por padrão. Um commitment configurado para renovar por mais três anos vai fazer isso silenciosamente, a menos que você verifique e atualize a configuração de renovação antes da janela de expiração. O Google geralmente permite cancelamentos em até sete dias após a renovação, mas não depois. Revise as configurações de renovação dos seus commitments como parte de qualquer auditoria rotineira de billing.
Decida entre on-demand e Editions projeto a projeto
Como a atribuição do modelo de pricing acontece por projeto, a abordagem correta é auditar projetos individualmente, em vez de buscar uma resposta única para a organização inteira. Projetos de desenvolvimento, teste e análises ad-hoc costumam se encaixar no on-demand; pipelines noturnos de ETL, backends de dashboard e produtos de dados recorrentes com consumo previsível de slots tendem a favorecer o Editions.
O sinal a observar: um projeto em que o consumo médio de slots ultrapassa consistentemente 50 slots vale ser avaliado para Editions. Um projeto em que o pico de uso de slots se concentra em uma janela diária previsível, como um job noturno de transformação, é um forte candidato a um commitment de baseline. Projetos com uso volátil ou esparso devem permanecer no on-demand, em que o pool compartilhado de slots não custa nada durante o tempo ocioso. Para um detalhamento completo de como avaliar a mudança, veja o guia BigQuery Editions da DoiT e o panorama de autoscaling.
Use o BI Engine para cachear queries repetidas de dashboards e ferramentas de BI
Looker e dbt são consistentemente os dois maiores drivers de custo de compute do BigQuery nos ambientes dos clientes. O padrão é o mesmo nos dois casos: uma ferramenta de BI ou uma camada de transformação acessa as mesmas tabelas centenas ou milhares de vezes por dia, cada query escaneando os mesmos dados e cobrando proporcionalmente. O custo de scan se acumula tanto no on-demand quanto no Editions.
O BI Engine é a camada de cache em memória do BigQuery. Ele fica na frente do storage do BigQuery e intercepta as queries que pode atender pelo cache, retornando resultados sem disparar um scan completo. Você reserva uma quantidade fixa de memória (cobrada por GB-hora), especifica as tabelas preferenciais para manter aquecidas, e o BI Engine cuida da população e da invalidação do cache automaticamente. Queries que batem no cache rodam mais rápido e não custam nada além da taxa de reserva.
O cálculo de ROI é direto: identifique qual service account sua ferramenta de BI usa, meça quantos dados ela escaneia por dia e em quais tabelas, e compare esse custo de scan com uma reserva de BI Engine dimensionada para manter essas tabelas em memória. Para workloads que batem repetidamente nas mesmas tabelas grandes com pequenas variações de intervalo de datas, a taxa de reserva costuma ser uma fração do custo de scan que ela substitui. Reservas de BI Engine podem ser redimensionadas ou deletadas sob demanda, então você não fica preso a um commitment fixo.
Materialized views complementam o BI Engine para queries pesadas em agregações. Se um dashboard recalcula repetidamente a mesma soma, média ou contagem sobre um dataset grande, uma materialized view pré-calcula essa agregação e armazena o resultado. Queries downstream leem o valor pré-calculado em vez de recalcular a cada execução. Combinadas com o cache do BI Engine, as duas técnicas eliminam grande parte do compute redundante que torna ferramentas de BI caras em ambientes BigQuery.
Reduza a frequência de jobs agendados e recorrentes
Queries agendadas que rodam com mais frequência do que os consumidores realmente precisam do output representam desperdício direto em qualquer modelo de pricing. Um dashboard que atualiza a cada hora, mas é consultado duas vezes por dia, carrega seis vezes o custo de compute necessário. Um relatório que roda toda noite, mas alimenta uma revisão semanal de negócio, poderia rodar semanalmente.
A conversa é tão organizacional quanto técnica. Consultar o INFORMATION_SCHEMA.JOBS filtrando por frequência de job e bytes processados dá aos times de engenharia os dados para defender a redução de cadência sem chutar o impacto. Jobs rodando com alta frequência que escaneiam grandes volumes e atendem consumidores que verificam resultados raramente são os alvos de maior impacto. Para um contexto mais amplo sobre otimização de custos em CloudOps, o framework da DoiT mostra como times estruturam esse tipo de trabalho contínuo de governança.
Faça backup e apague tabelas e partições sem uso
Tabelas que não são consultadas há meses ainda geram cobranças de storage ativo se receberem qualquer escrita, mesmo as incidentais, que resetam o relógio de 90 dias do long-term storage. Partições dentro de tabelas ativas que ficam fora dos intervalos úteis de query geram custo de scan se as queries não filtrarem corretamente. Os dois problemas são endereçáveis via políticas de expiração de partição e auditorias periódicas de tabelas.
A view INFORMATION_SCHEMA.TABLE_STORAGE do BigQuery mostra o tamanho da tabela, a última hora de modificação e a contagem de linhas no nível do projeto. Tabelas grandes, antigas e nunca consultadas são candidatas a arquivamento ou deleção. Definir a expiração de partição na criação da tabela evita o acúmulo de dados obsoletos no longo prazo, sem exigir limpeza manual contínua.
Como identificar problemas de custo no BigQuery antes que cheguem à fatura
O desafio estrutural da observabilidade de custos no BigQuery é que a tooling padrão te dá histórico, não alertas. O Cloud Monitoring e o INFORMATION_SCHEMA contam o que aconteceu; não interrompem trabalho caro em andamento nem sinalizam anomalias enquanto elas se desenvolvem.
Vários controles nativos te aproximam de uma detecção proativa. O parâmetro maximum_bytes_billed no nível da query impede que queries descontroladas isoladas cheguem ao fim. Alertas de uso de slot no Cloud Monitoring disparam quando o consumo de slots de uma reserva ultrapassa um limite, o que evidencia carga inesperada mesmo quando a query em si parece normal. Cloud Functions ou Cloud Workflows permitem implementar uma lógica de alerta mais sofisticada, como disparar uma notificação quando o consumo de slots de um projeto específico ultrapassa a média móvel por uma margem configurável.
Fique atento a egress cross-region entre compute e storage
O Google descontinuou recentemente o rótulo "multi-region" no BigQuery, que há muito tempo era enganoso. O que se chamava de US multi-region está fisicamente hospedado em us-central-1 na vasta maioria do tempo; o que se chamava de EU multi-region tipicamente está em europe-west-4. Se o seu dataset vive em uma única região como us-east-1 e o seu compute roda contra a região US, ou vice-versa, o Google te cobra egress cross-region em cada leitura. Essas cobranças aparecem como itens separados no console de billing sob SKUs que a maioria dos engenheiros não reconhece de imediato como egress.
O método de detecção: pesquise no seu export de billing por SKUs que correspondam ao padrão "General Data Transfer Networking Traffic for Google Cloud Cross Region/Inter Region". A presença dessa SKU no seu export confirma que está ocorrendo egress cross-region. Para rastrear a origem, procure por SKUs de compute Analysis ou Editions ao lado de SKUs de Storage ligadas a regiões diferentes no mesmo período de billing. A combinação te diz qual região de compute está lendo de qual região de storage. A correção é direta: colocar storage e compute na mesma região.
Verifique cobranças inesperadas de Dataplex e Data Lineage API
O Dataplex e a Data Lineage API geram cobranças que aparecem sob SKUs do Dataplex no console de billing, e muitos times incorrem nelas sem saber que esses serviços estão ativos. O Dataplex pode ser habilitado automaticamente via integrações, configurações de dataset ou features em trial, e continua escaneando e catalogando dados em segundo plano, esteja ou não alguém usando o catálogo ativamente. A Data Lineage API, mesmo quando habilitada de forma independente do Dataplex, pode disparar billing do Dataplex em certas configurações.
Se você vê cobranças de Dataplex Premium Processing Unit no seu export de billing e o seu time não está usando o Dataplex ativamente para descoberta de dados, linhagem ou governança, audite quais APIs estão habilitadas e se alguma integração ativou alguma delas. Desabilitar tanto a Dataplex API quanto a Data Lineage API em projetos onde não são necessárias elimina as cobranças de segundo plano por completo. Várias ferramentas gratuitas e open-source cobrem linhagem de dados sem disparar billing do Dataplex.
Detecte anomalias no nível do job, não só da reserva
A lacuna na tooling nativa é a detecção de anomalias no nível do job. O Cloud Monitoring opera no nível da reserva; ele consegue te dizer que o uso de slots subiu, mas não qual job causou o pico, a qual projeto ele pertence ou se o padrão é um evento isolado ou uma regressão recorrente. Sair de um pico de slots e chegar a um job responsável exige cruzamento manual com o INFORMATION_SCHEMA.JOBS, o que leva um tempo que o time geralmente não tem no momento.
Fechar essa lacuna exige consultar o INFORMATION_SCHEMA.JOBS de forma agendada, comparar os slot-milliseconds e bytes processados de cada job com a média histórica móvel dele e alertar quando um job desviar além de um limite configurável. O time de field data engineering da DoiT pode implementar essa camada de detecção para times que precisam, sem o overhead de construir e manter o pipeline internamente. Para mais sobre como pegar picos de custo antes que cheguem ao invoice, veja o post da DoiT sobre detecção de picos de custo no BigQuery.
Quando automatizar a otimização de custos no BigQuery
Otimização manual escala até certo ponto. Um time de engenharia que gerencia um punhado de projetos BigQuery consegue particionar tabelas-chave, ajustar configurações de reserva e auditar jobs agendados em uma cadência razoável. Esse mesmo time, gerenciando 40 projetos espalhados por várias unidades de negócio, não consegue acompanhar o trabalho de otimização junto com o desenvolvimento de features. O backlog cresce mais rápido do que o trabalho é entregue.
O argumento pela automação não é sobre substituir o julgamento de engenharia. É sobre garantir que esse julgamento atue sobre dados atuais, e não sobre auditorias defasadas. A detecção automatizada revela anomalias em tempo real; os engenheiros decidem o que fazer com elas. Recomendações automatizadas reduzem o esforço de diagnóstico; os engenheiros validam e implementam. A combinação produz tempos de resposta mais rápidos do que qualquer abordagem isolada.
O time de field data engineering da DoiT dá suporte às camadas de detecção e recomendação desse workflow, embutindo o monitoramento de custo diretamente em pipelines existentes e expondo descobertas no nível do job com contexto suficiente para agir sem investigação adicional. Esse trabalho se integra ao framework de Google Cloud FinOps da DoiT, então as descobertas de custo não ficam paradas em um dashboard esperando alguém abrir.
Times que querem fazer benchmark do estado atual antes de automatizar vão achar úteis o guia de KPIs de FinOps da DoiT e a visão geral das ferramentas de cloud cost analytics para estabelecer baselines e escolher a instrumentação certa.
Colocando a otimização de custos do BigQuery em bases sustentáveis
Otimização de custos no BigQuery em 2026 não é um projeto com data de conclusão. O modelo de pricing recompensa atenção contínua: baselines de slot que vão deslizando acima do uso real inflam a fatura silenciosamente; novas tabelas adicionadas sem políticas de partição acumulam custo de scan ao longo do tempo; jobs agendados criados para um caso de uso que não existe mais continuam rodando porque ninguém pensou em desligar. O custo da negligência se acumula devagar e aparece de repente.
Os times que mantêm o gasto com BigQuery sob controle tratam a otimização como uma prática contínua, e não como uma iniciativa periódica. Eles têm visibilidade da atribuição de custo no nível do job. Respondem a anomalias na janela em que ainda é possível endereçá-las. Tomam decisões de particionamento e clustering no momento da criação da tabela, não em retrospectivas de incidente. E têm um mecanismo para transformar descobertas em ação sem criar um backlog separado de tickets de otimização disputando espaço com o trabalho de features.
As capacidades de field data engineering da DoiT são desenhadas para sustentar o caminho do insight até a execução, de forma contínua, sem o overhead de auditorias manuais nem o atraso de invoices recebidos depois do fato. Fale com um engenheiro da DoiT sobre particionamento, clustering, tuning de slots e monitoramento contínuo de custo em todo o seu footprint do BigQuery.
Perguntas frequentes
Quando devo migrar do on-demand para o BigQuery Editions?
O sinal mais claro é um consumo consistente de slots acima de 50. A US$ 0,06 por slot-hora no Enterprise Edition, 100 slots rodando continuamente por um mês custam cerca de US$ 4.380, o que equivale aproximadamente a escanear 700 TiB no on-demand a US$ 6,25 por TiB. Se o seu volume mensal de scan se aproxima desse limite com timing previsível, o Editions provavelmente economiza dinheiro. Consulte o INFORMATION_SCHEMA.JOBS para obter o total de slot-milliseconds dos últimos 30 a 90 dias e calcular o seu break-even real antes de se comprometer.
Quais são os três BigQuery Editions e como se diferenciam?
O Standard Edition atende times de analytics com workloads moderados e consistentes. Suporta autoscaling com pricing pay-as-you-go a US$ 0,04 por slot-hora (região US), mas não oferece commitments multianuais nem compartilhamento de slots ociosos. O Enterprise Edition adiciona criptografia CMEK, capacidade de BI Engine, table snapshots e descontos de commitment de 1 ou 3 anos, sendo a escolha certa para workloads de produção com requisitos de segurança ou governança. O Enterprise Plus adiciona disaster recovery cross-region, backup gerenciado e SLA de 99,999%, e é desenhado para deployments mission-critical em que indisponibilidade traz consequências regulatórias ou contratuais.
Como evito que uma única query gere uma fatura enorme no BigQuery?
Defina o parâmetro maximum_bytes_billed no nível da query ou do job. Qualquer query que tentaria escanear mais bytes do que o limite configurado falha imediatamente, em vez de completar e gerar a cobrança. Para projetos on-demand, essa configuração funciona como teto rígido de gasto por query. Para projetos Editions, ela limita o consumo de slots ao capear o volume de scan que dirige a complexidade da query. Você pode definir esse parâmetro na API do BigQuery, no console e em client libraries, além de impor isso como política organizacional via os controles de configurações de query do Google Cloud.