Power BI lento? O problema costuma estar no modelo, não no computador

Open Mind IA · 30 de setembro de 2026 · 10 min de leitura

Todo mundo que já colocou um relatório de Power BI em produção conhece a cena: o painel que na primeira semana parecia mágico, com o tempo, passa a levar dez, quinze, trinta segundos para responder a um simples clique em um filtro. O gestor clica, espera, desiste e volta para a planilha. A conclusão apressada costuma ser que "o Power BI é lento" ou que "o computador precisa de mais memória". Na maior parte dos casos que acompanhamos, nenhuma das duas explicações está certa.

O que quase sempre existe por trás de um relatório lento é a forma como os dados foram organizados. O Power BI é construído sobre um motor de análise em memória extremamente eficiente, mas esse motor foi pensado para trabalhar com um desenho específico de modelo. Quando o modelo foge desse desenho, por exemplo, com uma única tabela gigante e larga, cheia de colunas repetidas, o motor precisa trabalhar muito mais para responder a mesma pergunta.

Neste artigo explicamos, sem jargão desnecessário, o que é o modelo estrela, por que ele faz tanta diferença no desempenho, quais são os erros mais comuns que deixam um relatório pesado e como começar a corrigir isso na sua empresa. A ideia é que você consiga conversar com quem cuida dos seus dashboards, seja um time interno ou um parceiro, e saber exatamente o que perguntar.

O que significa um relatório "lento" de verdade

Antes de procurar culpados, vale separar três tipos de lentidão, porque cada uma tem uma causa diferente. A primeira é a lentidão de atualização: o tempo que os dados levam para ser recarregados da origem, seja um ERP, um banco de dados ou uma planilha. A segunda é a lentidão de abertura: o tempo até o relatório aparecer na tela. A terceira, e a que mais irrita o usuário, é a lentidão de interação: o tempo entre clicar em um filtro, uma segmentação ou um gráfico e ver o resultado mudar.

O modelo de dados influencia principalmente a terceira, mas também afeta as outras duas. Um modelo desorganizado ocupa mais memória, o que deixa a abertura mais pesada, e exige transformações mais complexas na carga, o que alonga a atualização. Por isso, quando alguém diz que o dashboard está lento, o primeiro passo é perguntar em qual dessas situações isso acontece. Sem essa distinção, é comum gastar semanas otimizando o lugar errado.

O que é o modelo estrela, explicado para quem não é da área de dados

Imagine uma loja que registra todas as vendas em um único caderno gigante. Cada linha traz a data, o nome do cliente, o endereço do cliente, o nome do produto, a categoria do produto, o vendedor, a filial e, por fim, o valor vendido. Se o mesmo cliente comprou cem vezes, o nome e o endereço dele aparecem cem vezes. Se você quiser saber quantos clientes existem, precisa varrer o caderno inteiro e descontar as repetições. Esse caderno é o equivalente a uma tabela única e larga, muito comum quando os dados vêm direto de uma exportação.

O modelo estrela organiza a mesma informação de outro jeito. No centro fica uma tabela de fatos, que guarda apenas o que aconteceu: cada venda, com a data, os códigos do cliente, do produto e do vendedor, e os valores numéricos. Ao redor ficam as tabelas de dimensões, que descrevem os personagens: uma tabela de clientes, uma de produtos, uma de vendedores, uma de datas. Cada cliente aparece uma única vez, e a tabela de fatos apenas aponta para ele. Desenhado no papel, o resultado lembra uma estrela, com a tabela de fatos no meio e as dimensões nas pontas.

Essa separação parece um detalhe de organização, mas tem consequências práticas enormes. Filtrar por cliente, por período ou por produto passa a significar filtrar uma tabela pequena de descrições e deixar que o filtro "escorra" até a tabela de fatos por meio dos relacionamentos. É exatamente esse tipo de operação que o motor do Power BI faz de forma muito rápida.

Por que o modelo estrela deixa tudo mais rápido

O motor do Power BI armazena os dados em colunas e os comprime. Essa compressão funciona melhor quando uma coluna tem poucos valores distintos e muita repetição, como uma coluna de "código da filial". Em uma tabela única e larga, textos longos como nome de cliente ou descrição de produto se repetem milhões de vezes e são armazenados junto com os números. No modelo estrela, esses textos ficam nas dimensões, que são pequenas, e a tabela de fatos guarda apenas códigos numéricos curtos, que comprimem muito bem.

O resultado é um arquivo menor, que ocupa menos memória e é lido mais depressa. Além disso, as medidas em DAX, a linguagem de cálculo do Power BI, ficam mais simples quando o modelo é limpo. Uma soma de faturamento por mês, por exemplo, depende apenas da tabela de fatos e da tabela de datas. Em modelos confusos, o mesmo cálculo precisa de filtros extras e contornos que consomem tempo de processamento a cada clique.

Há ainda um ganho menos óbvio: a confiabilidade. Quando cada informação mora em um único lugar, o número de vendas por cliente é o mesmo em todas as páginas do relatório. Muitos casos de "números diferentes em telas diferentes" nascem de modelos em que a mesma informação foi copiada e tratada de formas distintas.

Os erros de modelagem que mais pesam nos relatórios

Na prática, o desempenho ruim raramente vem de um único grande erro. Ele é o acúmulo de pequenas escolhas que, somadas, sobrecarregam o motor. Os problemas que mais encontramos em diagnósticos são estes:

• Tabela única e larga: tudo em uma só tabela, com dezenas de colunas de texto repetidas em cada linha, em vez de fatos separados de dimensões.
• Colunas que ninguém usa: campos importados por precaução, como códigos internos, observações longas e datas de auditoria, que ocupam memória sem aparecer em nenhum gráfico.
• Colunas de data e hora com precisão excessiva: guardar o horário até o segundo cria milhões de valores distintos e prejudica a compressão; na maior parte das análises, a data é suficiente.
• Relacionamentos de muitos para muitos sem necessidade: eles funcionam, mas tornam os cálculos mais caros e podem gerar resultados difíceis de explicar.
• Ausência de uma tabela de calendário: deixar que o Power BI crie datas automáticas para cada coluna de data infla o modelo e complica análises como comparativos entre períodos.
• Colunas calculadas onde bastaria uma medida: colunas calculadas ocupam espaço no modelo; medidas são calculadas apenas quando necessárias.

Repare que quase todos esses pontos têm a mesma raiz: importar tudo "do jeito que veio" da origem. É compreensível, porque no começo de um projeto o objetivo é mostrar resultado rápido. O custo aparece meses depois, quando o volume de dados cresce e o modelo deixa de aguentar.

O papel da tabela de calendário

Uma tabela de datas dedicada merece destaque porque resolve dois problemas de uma vez. Ela permite análises de tempo consistentes, como mês contra o mesmo mês do ano anterior, acumulado do ano e média móvel, e evita que o Power BI mantenha tabelas de datas ocultas para cada campo de data do modelo. Em bases com muitas colunas de data, como pedido, emissão, vencimento e pagamento, essa diferença é significativa.

Onde o desempenho também se perde: a origem dos dados e a transformação

Nem toda lentidão se resolve dentro do Power BI. Muitas vezes o ganho maior está antes, na forma como os dados chegam. Quando o relatório busca informações diretamente de tabelas transacionais do ERP, sem nenhum tratamento, cada atualização precisa varrer volumes enormes e aplicar transformações pesadas. Levar esse trabalho para uma camada intermediária, como uma visão preparada no banco de dados ou um fluxo de dados reutilizável, deixa a carga mais leve e evita que várias pessoas refaçam as mesmas transformações em arquivos diferentes.

Outro ponto é a atualização incremental. Em vez de recarregar cinco anos de histórico a cada rodada, o relatório recarrega apenas o período recente, como os últimos dias ou meses, e mantém o restante intacto. Para bases grandes, isso reduz o tempo de atualização de forma dramática e diminui a carga sobre o sistema de origem, que normalmente também atende a operação da empresa.

Vale ainda cuidar do que aparece na tela. Uma página com muitos visuais carrega todos ao mesmo tempo, e cada visual dispara sua própria consulta ao modelo. Reduzir a quantidade de gráficos por página, evitar tabelas com centenas de linhas e usar navegação entre páginas para separar visão executiva de detalhamento melhora a sensação de velocidade mesmo antes de qualquer ajuste técnico.

Como começar a diagnosticar o seu relatório

A boa notícia é que dá para avançar bastante sem reconstruir nada do zero. O primeiro passo é medir. O Power BI Desktop tem um analisador de desempenho que registra quanto tempo cada visual leva para carregar e qual parte desse tempo é consulta e qual é renderização. Com ele, é possível identificar rapidamente se o gargalo está em um cálculo específico, em um visual pesado ou no modelo como um todo.

O segundo passo é olhar o tamanho e a composição do modelo. Ferramentas de análise externas mostram quais tabelas e colunas ocupam mais memória. É comum descobrir que duas ou três colunas de texto respondem por boa parte do arquivo. Remover ou reestruturar essas colunas costuma render o maior ganho com o menor esforço.

Com essas informações em mãos, uma sequência prática de trabalho seria:

• Mapear as perguntas de negócio: listar o que o relatório precisa responder, para saber quais colunas realmente importam.
• Remover o que não é usado: excluir colunas e tabelas sem função nos visuais, nas medidas ou nos relacionamentos.
• Separar fatos e dimensões: quebrar a tabela larga em uma tabela de fatos enxuta e dimensões descritivas.
• Criar uma tabela de calendário única: e desativar as datas automáticas.
• Revisar as medidas: trocar colunas calculadas por medidas quando possível e simplificar cálculos com muitos filtros aninhados.
• Medir de novo: repetir o analisador de desempenho e comparar antes e depois, para saber o que realmente funcionou.

Um cuidado importante: faça uma mudança de cada vez e teste. Quando várias alterações são feitas juntas, fica impossível saber qual delas trouxe o ganho, e uma alteração mal feita pode quebrar medidas que outras pessoas já usam.

Quando vale a pena reconstruir o modelo

Há situações em que ajustes pontuais não resolvem, e o mais econômico no longo prazo é refazer o modelo com calma. Os sinais mais claros são: o relatório já passou por várias rodadas de correção e continua lento, cada nova pergunta do negócio exige gambiarras, os números divergem entre páginas ou a atualização já não termina dentro da janela disponível. Nesses casos, cada correção paliativa aumenta a complexidade e torna o próximo ajuste mais difícil.

Reconstruir não significa jogar fora o trabalho anterior. As regras de negócio já validadas, como a definição de faturamento líquido ou de cliente ativo, são o ativo mais valioso e devem ser preservadas e documentadas. O que se refaz é a estrutura que as sustenta, para que a próxima ampliação, seja mais uma filial, mais um sistema ou mais anos de histórico, aconteça sem degradar a experiência de quem usa.

Conclusão: desempenho é consequência de um bom desenho

Um relatório de Power BI rápido raramente é fruto de truques de última hora. Ele é o resultado de um modelo bem desenhado desde o início, com fatos e dimensões separados, colunas escolhidas com critério, uma tabela de calendário dedicada e uma carga de dados pensada para crescer. Quando isso existe, o usuário clica e a resposta vem na hora, e é essa experiência que faz o dashboard virar hábito de gestão em vez de mais um painel esquecido.

Na Open Mind IA, tratamos a modelagem como a etapa que sustenta todo o resto do projeto de BI. Em diagnósticos de relatórios já existentes, medimos onde o tempo está sendo gasto, identificamos os ajustes de maior impacto e, quando necessário, reestruturamos o modelo preservando as regras de negócio da sua operação. Se o seu painel está lento, ou se você quer garantir que o próximo já nasça no desenho certo, conheça nossos cases de BI e veja como essa abordagem funciona na prática.