R$ 13.500 por mês em BigQuery. O problema não era a ferramenta.
Tenho um contrato de horas mensais com uma empresa do ramo alimentício. No dia a dia, cuido da infraestrutura de dados deles — pipelines, BigQuery, manutenção geral. Em uma dessas rotinas, olhei o billing do GCP e o número chamou atenção: R$ 13.511 por mês só de BigQuery.
Decidi investigar. Em algumas semanas, o custo caiu para R$ 1.268/mês. Uma redução de 90,6% — quase R$ 147 mil de economia por ano.
Fazia parte do meu papel otimizar os recursos utilizados. E o que encontrei não era um problema do BigQuery — era como ele estava sendo usado.
O diagnóstico: o que encontrei
Ao analisar o ambiente, identifiquei dois problemas que juntos multiplicavam o custo:
1. Nenhuma das 14 tabelas principais tinha particionamento
O BigQuery cobra por volume de dados processados em cada query. Quando uma tabela não tem partição, qualquer SELECT com filtro de data — mesmo que você só queira os dados de ontem — faz um full scan na tabela inteira.
No caso desse cliente, eram 14 tabelas com esse problema. A maior tinha 50 GB. Toda vez que uma query rodava contra essa tabela, o BigQuery processava os 50 GB completos, mesmo que a resposta estivesse em 500 MB.
Para visualizar o impacto, imagine a diferença:
A mesma query. O mesmo resultado. 125x mais barato.
2. Jobs rodando de hora em hora — inclusive de madrugada
Os pipelines de dados estavam configurados para executar a cada hora, 24 horas por dia. Isso significa 24 execuções diárias fazendo full scan em tabelas sem partição.
O detalhe: essa configuração foi feita no início do projeto e nunca mais foi revisada. Ninguém questionou se fazia sentido processar dados às 3h da manhã quando o time de negócios só acessava os dashboards no horário comercial.
A conta é simples:
- 14 tabelas × 24 execuções/dia × 30 dias = 10.080 full scans por mês
- Cada scan processando GBs desnecessários
- Resultado: R$ 13.511/mês
A solução: duas mudanças, zero ferramentas novas
Passo 1: Particionamento das 14 tabelas
A primeira ação foi aplicar particionamento por data em todas as 14 tabelas. No BigQuery, isso significa que os dados são organizados fisicamente em blocos por dia (ou mês, ou hora — depende do caso). Quando uma query filtra por data, o BigQuery lê apenas as partições relevantes, ignorando todo o resto.
Para tabelas já existentes com dados históricos, o processo foi:
Para cada tabela, o processo foi:
- Identificar a coluna de partição — geralmente a data do registro ou data de ingestão
- Criar a tabela particionada com
PARTITION BY - Migrar os dados da tabela original
- Validar contagem de registros e integridade
- Substituir a tabela original
Esse processo foi repetido nas 14 tabelas. A maior delas (50 GB) levou mais atenção na validação, mas o procedimento é o mesmo.
Dica importante: no BigQuery, você pode verificar quanto uma query vai processar antes de executar. O estimador de bytes no console mostra a diferença entre a tabela particionada e a original:
Tabela sem partição: "This query will process 50.2 GB"
Tabela com partição: "This query will process 487.3 MB"
Passo 2: Redução da frequência de execução
A segunda mudança foi rever a frequência dos pipelines. Sentei com a gerência que consumia os dados e fiz uma pergunta simples: "vocês precisam de dados atualizados a cada hora?"
A resposta: não. Os dashboards eram consultados de manhã e no final do dia. Dados atualizados duas vezes por dia eram suficientes.
Alterei o schedule dos pipelines de 24x/dia para 2x/dia: às 8h (antes do time chegar) e às 19h (consolidação do dia).
De 24 execuções para 2. Redução de 92% no volume de jobs.
O resultado
A combinação das duas mudanças gerou um efeito multiplicador:
- Particionamento reduziu o volume processado por query (de GBs para MBs)
- Redução de schedule reduziu o número de queries executadas (de 24 para 2)
| Métrica | Antes | Depois | Redução |
|---|---|---|---|
| Custo mensal BigQuery | R$ 13.511 | R$ 1.268 | 90,6% |
| Execuções por dia | 24 | 2 | 91,7% |
| Dados processados por query (tabela maior) | ~50 GB | ~500 MB | 99% |
| Economia anualizada | — | ~R$ 147.000 | — |
O projeto levou algumas semanas entre levantamento das tabelas, aplicação do particionamento, validação das mudanças e alinhamento com o time de negócios. Nenhuma ferramenta nova foi instalada. Nenhuma migração de plataforma. Nenhum custo adicional.
O que isso ensina
Esse caso ilustra um padrão que vejo se repetir em muitas empresas:
-
Configurações iniciais viram permanentes. Alguém configurou os jobs pra rodar de hora em hora no início do projeto — provavelmente fazia sentido naquele momento. Mas ninguém revisou depois. Infra de dados precisa de revisão periódica como qualquer outra infraestrutura.
-
O problema raramente é a ferramenta. Se alguém olhasse só o billing, a conclusão natural seria "BigQuery é caro, vamos migrar". Mas o BigQuery não era o problema — a forma como estava sendo utilizado é que gerava o custo. Antes de migrar, otimize.
-
Converse com quem consome os dados. A redução de 24x para 2x por dia só foi possível porque alinhei com a gerência. Se eu tivesse mudado sem perguntar, poderia ter criado um problema. A decisão técnica precisa de contexto de negócio.
-
Particionamento não é opcional. No BigQuery, tabelas sem partição em produção são um erro de arquitetura. O custo escala linearmente com o volume — e quando você percebe, já está pagando R$ 13k/mês.
Sua empresa pode estar no mesmo cenário
Se você usa BigQuery (ou qualquer data warehouse em cloud) e nunca fez uma revisão de custos, faça o teste:
Se não conseguiu marcar todos os itens, existe espaço para otimização.
Faça nosso Assessment de Maturidade de Dados — diagnóstico gratuito em 3 minutos com recomendações personalizadas.
Guilherme Colla é Data Engineer com 10 anos de experiência, 3x certificado GCP. Precisa de ajuda para otimizar seus custos de cloud? Entre em contato para uma consultoria personalizada.