Power BI Pro, PPU e Fabric capacity: como dimensionar e não pagar demais

Dimensionar capacity Power BI é decisão financeira, não só técnica#

Todo cliente que já usa Power BI há algum tempo chega à mesma encruzilhada: continuar comprando licenças Pro por usuário, migrar criadores para PPU, ou assumir uma capacity Power BI dedicada no Fabric. A dúvida raramente é técnica, é uma conta que envolve número de usuários, tamanho dos modelos, recursos que o negócio realmente precisa e quanto isso custa por mês de forma sustentável. Errar para menos gera throttling e usuários frustrados. Errar para mais significa pagar por capacidade ociosa todo mês.

Este artigo detalha os três modelos de licenciamento, o que cada faixa de capacity Fabric libera na prática, como o consumo é medido e cobrado (CU, throttling, smoothing, autoscale), como monitorar isso com o Fabric Capacity Metrics app e o que costuma causar estouro de capacity, além de caminhos concretos de economia. Se você ainda não decidiu se vale migrar para o Fabric como plataforma, vale complementar com nossa análise em Microsoft Fabric: o que é e vale a pena em 2026. Se o que falta é uma visão de custo total do projeto, incluindo consultoria e sustentação, veja quanto custa implementar Power BI em uma empresa em 2026.

Três modelos de licenciamento, três lógicas de custo diferentes#

Power BI Pro é licença por usuário, cobrada mensalmente, obrigatória para quem publica ou compartilha relatórios em workspaces colaborativos. É simples de orçar (multiplica por cabeça) e funciona bem quando o número de pessoas que interagem com o BI é pequeno e a maioria também cria conteúdo, não só consome.

Power BI Premium Per User (PPU) custa mais por usuário que o Pro, mas libera recursos de capacity, datasets maiores, refresh mais frequente, paginated reports, IA embarcada, sem exigir a compra de uma capacity inteira. É a ponte para equipes pequenas que precisam de recursos avançados mas ainda não têm volume de consumidores que justifique uma capacity dedicada.

Capacity Fabric, sucessora do antigo Power BI Premium por capacidade (a Microsoft parou de vender novos SKUs P1 a P5, restando os F-SKUs do Fabric, embora capacities Premium antigas continuem operando), é licenciada por poder de processamento compartilhado, não por usuário. A partir de um certo volume de consumidores, pessoas que só visualizam relatórios sem editar, a capacity fica proporcionalmente mais barata que multiplicar licenças Pro, porque quem só lê relatórios publicados em capacity não precisa de licença individual.

A tabela abaixo resume quando cada modelo tende a compensar, considerando não só o número de usuários mas também os recursos técnicos exigidos:

Perfil de uso	Modelo recomendado	Por que compensa
Até 25 usuários, todos criam e editam relatórios, modelos pequenos	Power BI Pro	Custo previsível por cabeça, sem overhead de capacity ociosa
Poucos criadores avançados precisando de datasets grandes ou paginated reports, sem volume de leitores	PPU	Libera recursos de capacity sem exigir capacity dedicada
Muitos consumidores de leitura, poucos criadores, mix acima de 3:1	Capacity Fabric (F64 ou superior)	Consumidores não pagam licença individual, custo dilui por usuário
Modelos grandes (acima de 1 GB), necessidade de Direct Lake ou engenharia de dados no mesmo ambiente	Capacity Fabric	Recursos indisponíveis fora de uma capacity
Uso de Copilot ou outros recursos de IA generativa em escala	Capacity Fabric F64 ou superior	Requisito mínimo de capacity definido pela Microsoft
Múltiplos ambientes (dev, teste, produção) com deployment pipelines completos	Capacity Fabric	Pipelines de implantação em múltiplos estágios exigem capacity
Picos sazonais previsíveis (fechamento mensal, datas de pico de negócio)	Capacity Fabric com autoscale habilitado	Absorve picos sem throttling nem SKU fixo superdimensionado o ano todo

Na prática, a virada de chave costuma acontecer entre 60 e 100 usuários totais, ponto em que vale simular o custo de uma capacity contra a soma de licenças Pro ou PPU. Abaixo disso, licenciamento por usuário costuma ser mais simples de administrar e mais barato. Os valores exatos mudam com frequência e variam por região, moeda e programa de compra (CSP, EA, direto), por isso o número certo vem sempre de uma cotação atual, não de tabela de preço genérica.

O que a capacity libera que Pro e PPU não entregam#

Uma capacity Power BI, seja PPU seja Fabric, não é só "mais licença cara", ela destrava recursos que simplesmente não existem no plano Pro:

• Modelos semânticos grandes: o Pro limita o dataset a 1 GB; capacity permite dezenas ou centenas de gigabytes, com o Large Semantic Model Storage Format.
• Paginated reports: relatórios pixel-perfect (formato SSRS) para notas fiscais, boletos e extratos, indisponíveis no Pro.
• Direct Lake: leitura direta dos arquivos Delta do OneLake sem duplicação de dados, exclusiva de capacity Fabric, tema detalhado no artigo sobre Fabric citado acima.
• Copilot e IA generativa: exigem, hoje, capacity F64 ou superior (ou P1 equivalente), indisponíveis em workspace Pro.
• Deployment pipelines completos: promoção controlada de conteúdo entre desenvolvimento, teste e produção, com histórico de mudanças.
• Refresh incremental em escala: o Pro limita a frequência de atualização agendada; capacity permite refresh incremental de tabelas enormes sem reprocessar tudo.
• XMLA endpoint de leitura e escrita: integração com Tabular Editor, DAX Studio e escrita programática no modelo.

Esses recursos, isoladamente, raramente justificam o salto de custo. Migrar para capacity costuma fazer sentido quando dois ou três aparecem juntos, com volume de consumidores relevante.

Os SKUs de capacity Fabric: de F2 a F512 e acima#

Os SKUs de capacity Fabric são identificados pela letra F seguida do número de Capacity Units (CU) que entregam, de F2 (2 CU) a F2048 (2.048 CU). Quem vinha de Power BI Premium reconhece a equivalência: F64 corresponde ao antigo P1, F128 ao P2, e assim sucessivamente.

SKU	CUs	Equivalente Premium	Custo aproximado (pay-as-you-go, mensal)	Perfil de uso típico
F2	2	sem equivalente	~US$ 262	POC, ambiente de testes, poucos relatórios pequenos
F8	8	sem equivalente	~US$ 1.050	Um departamento, cargas leves de refresh
F16	16	sem equivalente	~US$ 2.100	Múltiplas equipes, modelos médios
F32	32	sem equivalente	~US$ 4.200	Organização de porte médio, vários workspaces ativos
F64	64	P1	~US$ 8.400	Empresa inteira, centenas de consumidores, mínimo exigido para Copilot
F128	128	P2	~US$ 16.800	Grande volume de dados e múltiplos workloads Fabric simultâneos
F256	256	P3	~US$ 33.600	Engenharia de dados pesada rodando na mesma capacity do BI
F512 e acima	512+	P4 / P5	US$ 67.000+	Operações em larga escala, multi-área, alto paralelismo

Valores de referência em dólar, região US East, sujeitos a variação cambial e a descontos de até 40% via reserva de 1 ou 3 anos contratada no Azure. Cotar no Azure Pricing Calculator, com a região e o modelo de compra reais, é obrigatório antes de orçar qualquer projeto que dependa de capacity.

Como dimensionar de verdade: CU, throttling e smoothing#

A unidade de medida da capacity é a Capacity Unit (CU), um pool compartilhado consumido por dois tipos de operação: interativas (abrir um relatório, rodar uma consulta DAX, interagir com um dashboard) e em segundo plano (refresh agendado, dataflows, jobs de Spark quando o Fabric é usado além do Power BI).

A Microsoft aplica "smoothing" sobre esse consumo: operações interativas são suavizadas numa janela curta, de minutos, e operações em segundo plano numa janela de 24 horas. Um refresh noturno pesado não necessariamente derruba a capacity no instante em que roda, o custo dele se distribui ao longo do dia. Mas consumo sustentado acima do limite contratado, mesmo suavizado, eventualmente aciona o throttling.

O throttling acontece em estágios, não é um interruptor único: primeiro atraso nas operações interativas, depois rejeição de novas operações interativas e, em estágio mais severo, rejeição também de operações em segundo plano, refreshs param de rodar até o consumo normalizar. É o sintoma mais visível de capacity subdimensionada, e o motivo pelo qual "comprar um SKU grande demais para nunca dar problema" parece, à primeira vista, a solução mais simples.

O problema é que superdimensionar tem custo direto e recorrente. O dimensionamento correto exige medir carga real: picos de uso, tamanho e frequência de refresh dos modelos maiores, usuários simultâneos em horário de pico, não estimar por "achismo" nem comprar o maior SKU do catálogo por segurança.

Autoscale: rede de segurança, não substituto de bom dimensionamento#

O Fabric oferece autoscale de capacity: a capacity absorve picos de consumo além da CU base sem entrar em throttling, sendo cobrada pela CU adicional usada durante o pico, com multiplicador máximo configurável (comumente até três vezes a base).

Isso ajuda em picos legítimos e pontuais, fechamento de mês, campanhas, eventos sazonais, onde comprar uma capacity fixa maior o ano todo seria desperdício na maior parte do tempo. Mas autoscale mal configurado, sem alerta de consumo nem revisão periódica, vira um jeito silencioso de a fatura crescer sem ninguém perceber. Autoscale reduz o risco de throttling, não substitui a disciplina de entender se o pico é recorrente o suficiente para justificar aumentar a capacity base em vez de pagar o adicional todo mês.

Como monitorar consumo: o Fabric Capacity Metrics app#

O aplicativo Fabric Capacity Metrics, instalado a partir de um template oficial da Microsoft e conectado com a conta de administrador da capacity, é a ferramenta central para acompanhar consumo real. Ele mostra, entre outras coisas:

• Utilização de CU ao longo do tempo, por capacidade, com granularidade suficiente para identificar picos específicos.
• Consumo por item individual, qual dataset, relatório, dataflow ou job de Spark consumiu mais CU num período.
• Eventos de throttling, quando aconteceram e em qual estágio (atraso, rejeição interativa, rejeição em segundo plano).
• Detalhamento por "timepoint", intervalos curtos que permitem investigar exatamente o que rodou no momento de um pico.

Sem esse monitoramento, o time de BI só descobre que a capacity estourou quando um usuário reclama que o relatório está lento, o que já é tarde. Empresas que tratam a capacity como infraestrutura crítica, e não como um item comprado uma vez e esquecido, revisam esse painel com regularidade, o mesmo tipo de disciplina que aplicamos em contratos de sustentação de BI.

Por que a capacity estoura (e nem sempre é falta de poder de processamento)#

Throttling costuma ser interpretado como "a capacity é pequena demais", mas na prática as causas mais comuns são outras, e comprar um SKU maior sem resolvê-las apenas adia o problema:

• Consulta ruim: medidas DAX que iteram sobre tabelas inteiras sem otimização, relacionamentos mal desenhados, relatórios com dezenas de visuais numa única página, cada abertura consome CU proporcional à ineficiência da consulta.
• Refresh pesado: refresh completo de tabelas fato grandes em vez de incremental, ou vários datasets grandes agendados para o mesmo horário, competindo pela mesma capacity.
• Capacity subdimensionada: SKU comprado com base no orçamento disponível, não na carga real medida, gera throttling crônico desde o primeiro mês de uso mais intenso.
• Capacity generosa demais: SKU grande comprado "para não faltar" e usado a uma fração da capacidade contratada, com reserva de um ano travando esse desperdício por doze meses.
• Falta de segregação: um workspace de teste ou relatório mal escrito numa área compartilhando a capacity de produção de outra, um problema local vira indisponibilidade para todos.

Identificar qual dessas causas está em jogo exige olhar o Metrics app antes de decidir comprar mais capacity. Em boa parte dos diagnósticos que fazemos, o problema não é a capacidade, é o modelo ou o agendamento de refresh, algo que se resolve com trabalho de modelagem de dados, não com mais CU.

Como economizar sem sacrificar performance#

Depois de entender causa e consumo real, existem caminhos concretos de redução de custo:

1. Pausar a capacity fora do horário de uso: capacities compradas via Azure podem ser pausadas e retomadas, interrompendo a cobrança enquanto pausadas. Útil em ambientes de desenvolvimento e teste, que não precisam ficar ativos 24 horas.
2. Reservar capacidade: para uso estável de longo prazo, uma reserva de 1 ou 3 anos no Azure reduz o custo mensal em relação ao pay-as-you-go.
3. Otimizar o modelo antes de aumentar o SKU: refresh incremental, esquema estrela, redução de cardinalidade, revisão de medidas DAX ineficientes. Um modelo bem construído consome uma fração da CU de um modelo mal desenhado fazendo o mesmo trabalho.
4. Usar autoscale para picos pontuais: em vez de manter capacity grande fixa o ano todo por dois ou três picos sazonais, dimensionar a base para a carga normal e deixar o autoscale absorver a exceção.
5. Segregar ambientes e reagendar refreshs: capacity menor para desenvolvimento e teste, capacity dedicada para produção, e horários de atualização de datasets grandes distribuídos ao longo da noite em vez de concentrados no mesmo intervalo.

Nenhuma dessas ações substitui a outra, o resultado sustentável vem de combinar dimensionamento correto, modelo otimizado e monitoramento contínuo.

Perguntas frequentes#

Qual a diferença entre Power BI Premium e capacity Fabric? O Power BI Premium era vendido em SKUs P1 a P5, hoje descontinuados para novas vendas. A capacity Fabric, vendida em SKUs F, segue a mesma lógica de processamento compartilhado, mas cobre também os workloads de engenharia de dados do Fabric, não só o Power BI. Capacities Premium antigas continuam funcionando para quem já as possuía.

Quantos usuários uma capacity F64 suporta? Não existe número fixo. Depende do tamanho dos modelos, da frequência de refresh e da complexidade das consultas. F64 costuma ser referência para uma organização de porte médio com centenas de consumidores, mas o dimensionamento correto vem de medir a carga real com o Metrics app, não de uma tabela genérica.

Licença Power BI PPU vale a pena para poucos usuários? Sim, quando o problema é recurso, não é volume. Poucos criadores avançados precisando de datasets grandes, paginated reports ou refresh mais frequente sem justificar o custo de uma capacity inteira é o cenário clássico de PPU.

O que acontece quando a capacity Power BI estoura? Throttling em estágios: primeiro atraso nas operações interativas, depois rejeição de novas operações interativas, e em estágio mais severo rejeição também de operações em segundo plano, como refreshs, até o consumo normalizar.

Dá para economizar pausando a capacity fora do horário comercial? Sim, para capacities compradas via Azure. Pausar interrompe a cobrança durante o período parado, o que é especialmente útil em ambientes de desenvolvimento e teste que não precisam ficar ativos fora do horário de trabalho.

Autoscale resolve o problema de dimensionamento da capacity? Reduz o risco de throttling durante picos, mas não substitui um dimensionamento correto da base. Sem alerta de consumo e revisão periódica, autoscale mal configurado pode virar gasto extra recorrente sem que ninguém perceba até a fatura chegar.

Fechando a conta#

Dimensionar capacity Power BI corretamente não é escolher o SKU mais seguro nem o mais barato, é entender o perfil real de uso, quantos criadores, quantos consumidores, que tamanho de modelo, que recursos o negócio precisa, e medir consumo real com o Metrics app antes de decidir. A maioria dos estouros de capacity que vemos em diagnóstico não nasce de falta de poder de processamento, nasce de modelo mal otimizado, refresh mal agendado ou capacity comprada sem base em dado nenhum.

Se você quer uma avaliação honesta de qual modelo de licenciamento e qual SKU fazem sentido para o seu volume real de uso, conheça nossos serviços de Power BI ou fale com a gente para um diagnóstico de consumo e custo aplicado ao seu cenário.