Como dimensionar capacidade no Microsoft Fabric sem estourar o orçamento

Capacidade não é servidor: é orçamento por segundo

A primeira confusão que vemos em projetos de Fabric é tratar a capacidade como se fosse uma máquina virtual. Ela não é. Uma SKU F é um pool de unidades de computação consumidas por operação — cada refresh de dataset, cada consulta DAX, cada notebook e cada pipeline retira unidades desse pool.

A consequência prática é que o gargalo raramente aparece onde se espera. Um único dataflow mal escrito rodando de hora em hora pode custar mais capacidade do que centenas de usuários abrindo relatórios. Antes de aumentar a SKU, é preciso saber quem está consumindo.

Os três consumidores que quase sempre explicam a conta

Em praticamente todo ambiente que auditamos, o consumo se concentra em três lugares. Primeiro, refreshes completos de modelos grandes que poderiam ser incrementais — reprocessar cinco anos de histórico toda madrugada é o desperdício mais comum e o mais fácil de corrigir.

Segundo, transformação feita no lugar errado: Power Query resolvendo o que deveria ser resolvido no lakehouse ou no warehouse, repetido a cada carga. Terceiro, relatórios com medidas DAX que varrem tabelas de fatos inteiras a cada interação do usuário, multiplicando o custo pelo número de acessos.

Corrigidos esses três pontos, é comum um ambiente voltar a caber na SKU que já estava contratada — sem trocar nada de licença.

Smoothing e throttling: por que o pico importa mais que a média

O Fabric distribui o consumo ao longo do tempo (smoothing), o que dá alguma folga para picos curtos. Mas quando o débito acumulado passa do limite, começa o throttling: as operações entram em fila e o usuário sente lentidão sem que nada esteja 'fora do ar'.

É por isso que monitorar apenas a média de utilização engana. O que precisa ser observado é o padrão de pico — normalmente concentrado na janela de refresh — e a sobreposição entre cargas automáticas e horário de uso humano. Distribuir refreshes ao longo do dia muitas vezes resolve mais que dobrar a capacidade.

Um roteiro de decisão em quatro passos

Antes de mexer na SKU, siga esta ordem: (1) inventarie o ambiente e descubra o que existe, quem é dono e o que ninguém acessa; (2) meça o consumo por item e identifique os cinco maiores; (3) otimize os campeões de consumo — refresh incremental, transformação na camada certa, revisão de DAX; (4) só então redimensione, com base em dados e não em impressão.

Ambientes com pausas programadas (desenvolvimento e homologação fora do horário comercial) e workspaces separados por criticidade tendem a manter custo previsível ao longo do ano. É exatamente esse acompanhamento contínuo que automatizamos no FabricBoard.