Cheat Sheet: Power BI Embedded na capacidade mínima

Os limites que mandam no jogo#

Na capacidade mínima, cada modelo tem teto de 3 GB de memória e cada consulta DAX, de 1 GB; um refresh completo pode mais que dobrar a memória usada pelo modelo. Fonte: What is Power BI Premium? (Microsoft Learn).

• O teto de memória é por modelo, não cumulativo. Refreshes de modelos diferentes não somam memória entre si; o que limita é o pico de cada modelo.
• Refresh completo = cópia antiga + cópia nova + consultas em curso. Um modelo de 1,5 GB em memória já arrisca estourar 3 GB durante o refresh. Regra prática conservadora: até ~1,2 GB em memória por modelo de importação, ou refresh incremental/particionado.
• A1 equivale a F8 em computação (8 CU). Se a sua mínima é F2, você tem um quarto do CPU de um A1 e um único refresh de modelo por vez.
• Visual que passa de 225 segundos é cortado e não renderiza.

Throttling e smoothing: a conta que explica a lentidão#

A capacidade não trava ao passar de 100%: ela empresta até 10 minutos de capacidade futura e só depois atrasa ou rejeita pedidos. Todo refresh é cobrado em parcelas nas 24 horas seguintes. Fonte: Understand the Fabric capacity throttling policy (Microsoft Learn).

• Interativo (consultas de relatório): suavizado em 5 a 64 minutos, conforme o consumo.
• Background (refresh e afins): suavizado em 24 horas, em timepoints de 30 segundos.

Como reconhecer. Erros CapacityLimitExceeded ou "Cannot load model due to reaching capacity limits". Lentidão sem esses erros costuma ser design do modelo ou do relatório, não throttling: confira o gráfico Throttling antes de escalar.

Saídas de emergência (documentadas para F SKU). Operações já em andamento nunca são interrompidas.

• Escalar a SKU temporariamente: mais folga por timepoint queima o carryforward mais rápido.
• Pausar e retomar: a capacidade volta com consumo futuro zerado, mas o acumulado vira cobrança na hora e o conteúdo fica fora do ar enquanto pausada.
• Faturamento de excedente (capacity overage): evita o throttling, ao custo de 3× a tarifa normal.

Modelo semântico: checklist de corte de memória#

Encolher o modelo é a alavanca que mais rende: cada GB a menos vira folga para refresh e consultas sob o teto de 3 GB. Fontes: Large semantic models (Microsoft Learn) e Configure workloads (Microsoft Learn).

• Ative o formato de modelo grande em todos os modelos e defina-o como padrão do workspace (Settings > Premium). Sem ele, o teto de tamanho offline é de 1 GB no F2, 2 GB no F4 e 3 GB no F8/A1. Com ele vem o on-demand load: só as páginas de dados consultadas sobem para a memória, e modelos despejados voltam mais rápido. Vale para A e F SKUs, e Brazil South é região suportada.
• Meça antes de cortar. VertiPaq Analyzer (DAX Studio) mostra o custo por coluna. Com o formato grande, a DMV DISCOVER_STORAGE_TABLE_COLUMN_SEGMENTS expõe Temperature e Last Accessed por coluna: coluna fria é candidata a sair.
• Remova colunas não usadas em relatórios, medidas, RLS e relacionamentos (Measure Killer ou Tabular Editor ajudam a achar).
• Ataque a cardinalidade. Separe data e hora, arredonde a hora para o minuto, tire IDs de transação, GUIDs e texto livre. Prefira decimal fixo ou inteiro a decimal flutuante.
• Desligue o Auto date/time no Desktop: ele cria uma tabela de datas oculta para cada coluna de data. Use uma única dimensão Data marcada como tabela de datas.
• Desligue hierarquias de atributo (IsAvailableInMDX = false, via Tabular Editor) em colunas que só são agregadas e nunca usadas como eixo, filtro, ordenação ou nível de hierarquia.
• Esquema estrela com chaves inteiras. Evite relacionamentos bidirecionais e muitos-para-muitos sem necessidade.
• Zero colunas e tabelas calculadas em DAX. Leve a lógica para a fonte (view SQL) ou para o Power Query com query folding.
• Corte linhas. Filtre histórico que ninguém consulta e reduza a granularidade quando o relatório não precisa do detalhe. Se precisar, use tabela agregada em importação com o detalhe em DirectQuery (modelo composto).
• Projete para o despejo. Modelos inativos saem da memória e recarregam no primeiro acesso, com atraso perceptível; quanto menor o modelo, mais rápido ele volta.

Refresh sem pico de memória#

Atualize menos dados, em pedaços e em fila: no F2 só um refresh de modelo roda por vez (F4: 2; F8/A1: 5), e o serviço recusa com 400 um segundo refresh do mesmo modelo. Fonte: Enhanced refresh with the Power BI REST API (Microsoft Learn).

• Refresh incremental em toda tabela fato grande. RangeStart/RangeEnd com query folding: só as partições recentes são reprocessadas, então só elas ganham cópia em memória. Ative "detectar alterações" se a fonte tiver coluna de última modificação.
• Refresh por objeto via Enhanced Refresh API. Fatos várias vezes ao dia, dimensões uma vez. Requer Premium, PPU ou Embedded, com escopo Dataset.ReadWrite.All.
• Baixe o maxParallelism (padrão 10) para 1 ou 2: menos threads, menor pico de memória, refresh um pouco mais longo.
• clearValues antes de full quando o pico não cabe: libera a cópia antiga, mas o modelo fica vazio durante a carga. Só em janela sem usuários.
• partialBatch com cautela: cada comando é confirmado sozinho; se falhar, o modelo pode ficar parcial. Não aceita applyRefreshPolicy: true.
• timeout curto (padrão 5 h) para falhar rápido em vez de queimar CU à toa; retryCount soma tentativas até o máximo de 24 h.
• Transformação na fonte, não no mashup. Power Query sem folding processa linha a linha durante o refresh. Prefira views SQL que entregam o dado pronto.
• Frequência pela fórmula de ocupação da seção de throttling: refresh de 15 em 15 minutos raramente se paga numa SKU de 2 ou 8 CU.
• Cuidado com pausa agendada. Se a capacidade Embedded for pausada no meio de um enhanced refresh, ele fica InProgress por até 6 h e só retoma se a capacidade voltar nesse prazo.
• Erro 0xC11C0020 = modelo despejado da memória durante o refresh. Reexecute; se for recorrente, é sinal de pressão de memória.

Exemplo de chamada enxuta (POST .../datasets/{id}/refreshes):

{
  "type": "full",
  "commitMode": "transactional",
  "maxParallelism": 2,
  "retryCount": 1,
  "timeout": "00:45:00",
  "objects": [ { "table": "fVendas" }, { "table": "dCliente" } ]
}

DAX que não estoura 1 GB por consulta#

Uma única consulta que materializa linhas demais estoura o limite de 1 GB e ainda queima CU de todos os usuários; quase sempre o culpado está nesta tabela.

Relatório com menos consultas por clique#

Cada visual da página aberta dispara ao menos uma consulta, e cada clique em slicer ou filtro cruzado refaz as consultas dos visuais afetados: menos visuais e menos interações significam menos CU.

• Página inicial enxuta. Referência prática: até 8 a 10 visuais com dados. Páginas ocultas só consultam quando abertas.
• KPIs num visual só. Um cartão (novo) com várias medidas ou uma tabela de KPIs no lugar de seis cartões: menos consultas, e medidas do mesmo visual podem ser fundidas em menos varreduras.
• Redução de consultas (Options > Query reduction): desligue o realce cruzado padrão e ponha botão Aplicar nos slicers e no painel de filtros. O usuário monta o filtro e dispara uma rodada só.
• Edite as interações. Desligue o filtro cruzado entre visuais que não precisam conversar.
• Detalhe atrás de drillthrough. Tabelas detalhadas vão para páginas de detalhe; tooltips de página também consultam a cada passada do mouse, então mantenha-as leves.
• Tabela e matriz com limite. Top N ou filtro obrigatório, nunca 100 mil linhas na tela, e "Mostrar itens sem dados" desligado.
• Slicer de alta cardinalidade (cliente, pedido) vira busca no painel de filtros ou slicer dependente de outro filtro.
• Visuais personalizados só certificados e necessários: cada um carrega código próprio dentro do iframe.
• Visuais de IA (Q&A, influenciadores-chave, decomposição com divisões por IA) são caros: evite na página inicial.
• Atualização automática de página só com intervalo alto e se o negócio exigir; cada ciclo é uma rodada de consultas por usuário conectado.

Embedding: carregamento rápido no front#

O maior ganho de tempo percebido vem de preparar o iframe enquanto o backend gera o token e de nunca recriar iframes. Fonte: Best practices for faster performance in Power BI embedded analytics (Microsoft Learn).

• powerbi.bootstrap() no carregamento da página, em paralelo à geração do token; depois powerbi.embed() no mesmo elemento (SDK 2.9 ou superior). O container precisa estar no DOM: esconda com visibility, nunca com display: none.
• powerbi.preload() nas telas anteriores (login, home) para baixar JS e CSS do embed antes de o usuário chegar ao relatório.
• Embed URL sempre da API Get Reports, nunca montada à mão: o parâmetro config da URL acelera o carregamento.
• Permissão só de leitura (Permissions.Read) quando não há edição: o SDK pula a inicialização dos componentes de edição.
• Filtros, bookmarks e slicers no config desligam o cache visual e o relatório só aparece depois das consultas. Se o estado inicial é sempre o mesmo, salve o relatório já com ele aplicado. Filtro de config não é segurança: isolamento de cliente é RLS.
• Trocar de relatório no mesmo iframe com novo powerbi.embed(element, config). Vários visuais do mesmo relatório cabem num iframe só (custom layout), em vez de um embed por visual.
• Token com folga. Gere um token para todos os relatórios e modelos da tela, guarde-o no backend até perto do vencimento e renove com report.setAccessToken(), sem recarregar o relatório.
• Query caching (configuração do modelo, disponível em Embedded) acelera a abertura do relatório.
• Meça com os eventos loaded e o primeiro rendered e compare com o mesmo relatório no powerbi.com: se lá também é lento, o problema está no modelo ou no relatório, não no embed.

// 1) Assim que a página carrega, prepara o iframe (ainda sem token)
powerbi.bootstrap(container, { type: 'report' });

// 2) Quando o backend devolver embedUrl e token:
const t0 = performance.now();
const report = powerbi.embed(container, {
  type: 'report',
  id: reportId,
  embedUrl,                               // da API Get Reports
  accessToken: embedToken,
  tokenType: models.TokenType.Embed,
  permissions: models.Permissions.Read,   // só leitura
  viewMode: models.ViewMode.View
});
report.on('loaded', () => console.log('loaded ms', performance.now() - t0));
report.on('rendered', () => {
  console.log('rendered ms', performance.now() - t0);
  report.off('rendered');                 // mede só o primeiro render
});

RLS e multi-tenant na capacidade pequena#

RLS barata é um filtro de igualdade numa dimensão pequena, propagado por relacionamento de direção única; a escolha entre modelo único e modelo por cliente muda com o teto de memória por modelo.

• Identidade efetiva no embed token (username, roles, datasets). Em app owns data, o username pode carregar o ID do cliente: dTenant[TenantId] = USERNAME().
• Filtro de papel só em dimensão pequena. Nada de LOOKUPVALUE, PATHCONTAINS ou FILTER sobre a fato dentro da regra: ela roda em toda consulta.
• Usuário com acesso a várias entidades = tabela ponte de segurança. Filtro bidirecional de segurança só se for indispensável, porque é caro.
• Teste com a RLS ligada: no DAX Studio, conecte com Roles e EffectiveUserName na connection string e compare os Server Timings com e sem papel.
• Isolamento é RLS, não filtro de relatório: filtros de config e de página podem ser removidos pelo usuário.

Com workspace por cliente, os service principal profiles ajudam a isolar e escalar o acesso do seu app.

DirectQuery e Direct Lake#

Na SKU mínima, DirectQuery é gargalo de concorrência, e Direct Lake troca o refresh caro por um framing barato, mas só existe em F SKU e tem guardrails rígidos. Fontes: What is Power BI Premium? e Direct Lake overview (Microsoft Learn).

DirectQuery

• Fila garantida com muitos usuários: 5 conexões simultâneas por modelo no F2/F4, 10 no F8/A1, e paralelismo de consulta 1. Cada visual de cada usuário disputa essas conexões.
• Assume referential integrity nos relacionamentos quando a integridade é garantida na origem: gera INNER JOIN em vez de OUTER JOIN.
• Dimensões em Dual e agregações em importação sobre a fato em DirectQuery: a maioria dos visuais nem chega na fonte.
• Índices e visões materializadas na fonte desenhados para os filtros que os visuais realmente aplicam.

Direct Lake (só F SKU; não roda em A1)

• Embed exige token V2. Com service principal, use conexão cloud com identidade fixa; service principal profiles não são suportados.
• Guardrails do F2 ao F8: 300 milhões de linhas, 1.000 arquivos Parquet e 1.000 row groups por tabela; 10 GB de modelo no OneLake; 3 GB de memória para paging.
• Se estourar: Direct Lake on OneLake falha no refresh e o modelo para de responder até as tabelas Delta serem otimizadas; Direct Lake on SQL cai para DirectQuery, mais lento. O limite de tamanho do modelo vale para todas as consultas; os outros, por consulta.
• Tabelas Delta bem mantidas (V-Order, compactação em poucos arquivos grandes, row groups grandes) são o que separa Direct Lake rápido de Direct Lake lento.
• Framing custa quase nada, mas a preparação de dados (Spark, pipelines, dataflows) passa a consumir CU; se rodar na mesma capacidade, compete com os relatórios.

Guard rails da capacidade#

Os padrões de fábrica são permissivos; aperte-os para que uma consulta ou um job descontrolado seja cancelado antes de derrubar todo mundo. Os valores sugeridos são ponto de partida, a calibrar com o Capacity Metrics. Fontes: Configure workloads (Microsoft Learn) e Surge Protection GA (Fabric Blog).

• Onde fica: configurações da capacidade, em OneLake catalog > Govern > Capacities > Workloads; surge protection numa seção própria. Vale para F, P, A e EM.
• Efeitos colaterais: timeout e limite de memória também atingem as consultas de cache pós-refresh, e o refresh pode aparecer como falho mesmo com os dados atualizados. O surge protection não é teto rígido (jobs em andamento terminam) e também recusa refreshes.

Monitoramento: onde olhar e o que alertar#

Monitore throttling, e não só % de CPU; descubra quais consultas e refreshes enchem a capacidade; e alerte antes de o cliente perceber. Fontes: Power BI Embedded monitoring data reference (Microsoft Learn) e throttling policy.

• Ponto cego: o Capacity Metrics app não mostra memória por modelo nem conexões DirectQuery. Para memória, use VertiPaq Analyzer, as DMVs e os erros de recurso.
• Escala por alerta (A SKU): a Microsoft publica o runbook ScaleUp-Automation-RunBook.ps1, que roda no Azure Automation disparado por alerta do Azure Monitor.
• Em F SKU, a integração do workspace com Log Analytics ou o workspace monitoring do Fabric cumprem o papel dos logs Engine.

Custo: pausar, reservar, escalar e separar#

Na SKU mínima, o dinheiro está em não pagar horas ociosas e em não subir de SKU por causa de background mal distribuído. Fontes: Preços do Power BI Embedded (Azure), throttling policy e What is Power BI Premium?.

• A1 ou F8? Mesma computação (8 CU). A SKU é só Power BI; F SKU tem reserva e roda Direct Lake e itens do Fabric. Compare os dois na calculadora do Azure para a sua região.
• Licenças: em app owns data, quem só visualiza não precisa de licença; quem publica precisa de Pro. Em user owns data (embed para a organização), SKUs abaixo de F64 exigem Pro ou PPU de cada usuário.
• No Brasil: o preço em reais do site é só referência. A cobrança é internacional, sujeita a câmbio e IOF, sem emissão de NF-e.

Diagnóstico rápido#

Antes de escalar a SKU, identifique o sintoma: a maioria aponta para uma causa específica com correção barata.

Kit de ferramentas#

Com estas ferramentas dá para medir antes de mexer e provar o ganho depois; as que usam XMLA precisam do endpoint habilitado na capacidade (leitura para diagnosticar, leitura e escrita para publicar).

Fontes#

Páginas consultadas em outubro de 2026; os limites por SKU mudam com frequência, então confira antes de decisões de compra.

• What is Power BI Premium? (Microsoft Learn)
• Understand the Fabric capacity throttling policy (Microsoft Learn)
• Large semantic models in Power BI Premium (Microsoft Learn)
• Configure workloads in a Premium capacity (Microsoft Learn)
• Enhanced refresh with the Power BI REST API (Microsoft Learn)
• Best practices for faster performance in Power BI embedded analytics (Microsoft Learn)
• Direct Lake overview (Microsoft Learn)
• Power BI Embedded monitoring data reference (Microsoft Learn)
• Surge Protection for Background Operation, GA (Microsoft Fabric Blog)
• Preços do Power BI Embedded (Microsoft Azure)