Como Reduzi 90% dos Custos de BigQuery com Particionamento e Schedule

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:

1. Identificar a coluna de partição — geralmente a data do registro ou data de ingestão
2. Criar a tabela particionada com PARTITION BY
3. Migrar os dados da tabela original
4. Validar contagem de registros e integridade
5. 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:

1. 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.

2. 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.

3. 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.

4. 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.