A maioria dos times de dados acredita que adicionar LIMIT 100 em uma query exploratória faz o banco parar de ler ao encontrar 100 linhas. No BigQuery, isso é uma ilusão cara. Nós vimos equipes queimando milhares de reais por mês em queries que deveriam custar centavos — e o culpado é um padrão de SQL que parece inofensivo.
O modelo de custo que ninguém lê
O BigQuery cobra por bytes lidos, não por linhas retornadas. Essa é a regra fundamental que muda tudo. Em um banco relacional tradicional, LIMIT 100 é eficiente porque a engine lê linha a linha e para. Em um banco colunar como o BigQuery, a leitura opera em blocos de colunas inteiras.
Quando você executa SELECT * FROM tabela LIMIT 100, a engine precisa recuperar as colunas solicitadas dos blocos de armazenamento antes de aplicar o corte. Em tabelas particionadas sem filtro de partição, isso frequentemente significa escanear partições inteiras — embora particionamento e clustering possam mitigar parcialmente o custo ao limitar o escopo do scan. Você paga pelo banquete e consome apenas a azeitona.
Na Tech86, quando auditamos contas de BigQuery de clientes, o padrão SELECT * ... LIMIT em tabelas grandes aparece consistentemente entre as top fontes de desperdício. Não é um erro de lógica — é um erro de modelo mental. O desenvolvedor projeta a query pensando em banco relacional, mas a engine executa em arquitetura colunar.
TABLESAMPLE SYSTEM: a física muda
O comando TABLESAMPLE SYSTEM (1 PERCENT) muda a física da operação. Em vez de escanear a tabela inteira e depois cortar, ele instrui a engine a ler blocos de dados aleatórios do disco até atingir a porcentagem de amostragem definida. A engine nunca lê mais do que o especificado.
Segundo testes internos na Tech86, uma query exploratória que processava 3,45 GB com LIMIT 100 passou a processar 172 MB com TABLESAMPLE SYSTEM (1 PERCENT). Uma redução de 95% no volume de dados processados — e no custo da query.
A diferença não é marginal. Em uma operação que roda dezenas de queries exploratórias por dia, a economia mensal pode chegar a milhares de reais. E a mudança de código é mínima: uma cláusula SQL substituindo outra.
O problema não é exclusivo do BigQuery
O conceito se aplica a qualquer banco com leitura em blocos. No PostgreSQL, a sintaxe muda para TABLESAMPLE BERNOULLI (1) ou TABLESAMPLE SYSTEM (1), disponível desde a versão 9.5. A diferença entre os dois métodos:
- BERNOULLI: amostragem linha a linha. Mais precisa estatisticamente, mas mais lenta porque a engine precisa visitar cada linha para decidir se inclui.
- SYSTEM: amostragem por página de disco. Mais rápida porque a engine decide por bloco inteiro, mas com variância maior porque linhas dentro do mesmo bloco tendem a ser correlacionadas.
Para exploração rápida, SYSTEM é suficiente. Para análises que exigem representatividade amostral rigorosa, BERNOULLI é mais seguro. Em ambos os casos, o I/O reduz drasticamente comparado a um SELECT * ... LIMIT que escaneia a tabela inteira.
A lição de FinOps por trás da sintaxe
FinOps não é ficar desligando servidor no fim de semana. FinOps é entender a arquitetura interna da ferramenta que você opera. Quando um time de dados faz exploração com LIMIT em tabelas de petabytes, não está apenas testando código — está drenando o OPEX da empresa por desconhecer o modelo de custo da plataforma.
Conhecer a sintaxe é comum. Entender o custo computacional da sintaxe é o que separa profissionais de amadores. A mesma query, escrita de formas diferentes, pode custar R$ 0,03 ou R$ 30. A diferença não está no resultado — está na física da execução.
Na Tech86, incluímos auditoria de padrões de query como parte padrão dos nossos projetos de FinOps. Identificar SELECT * ... LIMIT em tabelas grandes é um dos primeiros checks. A correção é simples, a economia é imediata, e o impacto acumula mês a mês.
Conclusão
O LIMIT 100 no BigQuery é o equivalente a encher o tanque do carro para dar a volta no quarteirão. Funciona, mas custa muito mais do que deveria. TABLESAMPLE SYSTEM é a ferramenta certa para o trabalho certo: exploração de dados com custo proporcional ao que você consome.
Se seu time de dados faz queries exploratórias em tabelas grandes sem TABLESAMPLE, está pagando por bytes que nunca usa. Nós podemos ajudar a identificar e corrigir esses padrões.