A diferença entre as SKUs não é “velocidade”. É orçamento diário de CU. Quem entende isso escolhe certo na primeira vez — e para de escalar por pânico.
Uma F2 entrega 2 CU. Como o dia tem 24 horas, o orçamento é 48 CU-hora por dia. F4 dobra para 96, F8 vai a 192. Todo o resto — bursting, smoothing, throttling — é a mecânica de distribuir esse orçamento. Um job background de 1 CU-hora consome cerca de 2,1% do dia de uma F2, e apenas 0,5% do dia de uma F8.
É por isso que a mesma carga que “funciona” numa F8 derruba uma F2: não é o pico que muda, é a fração do orçamento diário que ele ocupa.
Os números abaixo são faixas observadas em implantações reais, não garantia contratual. Servem para calibrar expectativa antes de assinar.
| F2 | F4 | F8 | |
|---|---|---|---|
| Orçamento diário | 48 CU-h | 96 CU-h | 192 CU-h |
| Usuários simultâneos confortáveis | até ~10 | ~10 a 30 | ~30 a 80 |
| Modelo import saudável | até ~1 GB | até ~3 GB | até ~8 GB |
| Refresh full diário | inviável em modelo médio | 1 modelo médio | 2 a 3 modelos médios |
| Jobs Spark junto com relatório | não | com janela separada | sim, com cuidado |
| Primeiro sintoma quando estoura | Interactive Rejection | Interactive Delay diário | Delay em pico de manhã |
Opinião impopular: F2 é excelente para desenvolvimento e para cargas pequenas de verdade — e é péssima escolha para “começar produção e ver no que dá”. O custo de um incidente é maior que a diferença de assinatura.
Se o seu consumo médio diário passa de 60% do orçamento da SKU, você não tem margem para o pico da manhã. Ou corta consumo, ou sobe de degrau — não existe terceira opção.
Muda: orçamento de CU, tamanho de modelo que cabe em memória, quantos jobs pesados convivem, e a partir de F64 o direito de consumo de relatório sem licença Pro por usuário. Não muda: as regras de smoothing, os limites de throttling (10 min / 60 min / 24 h) e a necessidade de medir. Escalar não te dá disciplina.
Dobrar a SKU resolve o sintoma por alguns meses e transforma um problema técnico em despesa recorrente. Antes de subir de degrau, meça 14 dias de consumo, identifique os três itens que dominam a lista de CU(s) e teste as correções óbvias — refresh incremental, staging desligado, dev fora da produção. Em boa parte dos casos, a SKU atual passa a sobrar.
Sim, o redimensionamento é operacional. O ponto de atenção é a dívida de consumo já acumulada: ela não desaparece com a mudança.
Economiza, mas pausar liquida o carry forward imediatamente — e cobra. Faça isso como rotina planejada, não como reação a um incidente.
Para isolar dev de produção, duas capacidades menores costumam ser melhores. Para um único modelo grande, não: memória e bursting não se somam entre capacidades.
Consumo real por item e workspace, tendência de semanas e o número que justifica (ou dispensa) o próximo degrau de SKU.
Por que a capacidade trava sem nada de anormal na tela.
Capacidade & CU Como analisar o Capacity MetricsA ordem de investigação em quatro passos, com os gráficos explicados.
Sete mudanças em ordem de retorno — antes de pensar em SKU maior.
Conteúdo técnico sobre Microsoft Fabric e Power BI para quem opera essas plataformas todo dia. Artigos novos toda semana.
Criado e mantido pela PRS Tecnologia para contribuir com a comunidade técnica de dados. Site independente, sem vínculo com a Microsoft e não oficial: não representa posições da empresa. Microsoft, Microsoft Fabric e Power BI são marcas de seus respectivos proprietários. · © 2026 · fabricmetrics.com.br
powerbiembed.com.brfabricboard.com.br