Como usar atualização incremental no Power BI: passo a passo

O refresh do seu modelo grande está estourando o tempo e a memória#

Se o seu relatório demora quinze, trinta, quarenta minutos para atualizar, ou pior, falha com erro de memória no meio da carga, você provavelmente está recarregando o histórico inteiro toda vez. Isso é desperdício. A atualização incremental Power BI existe justamente para resolver esse problema: em vez de reprocessar milhões de linhas que nunca mudam, você atualiza só a janela recente, que é onde os dados realmente se movem.

Na prática, um modelo de vendas com cinco anos de histórico não precisa reler 2019 todo santo dia. O que muda é o mês corrente, talvez os últimos dez dias. A atualização incremental particiona a tabela por data e diz ao Power BI: recarregue apenas esta faixa, mantenha o resto congelado. O resultado costuma ser refresh de minutos em vez de dezenas de minutos, menos consumo de memória e menos pressão na fonte de dados.

Este é um tutorial direto. Vou mostrar quando usar, o passo a passo de configuração no Power BI Desktop, os erros que mais derrubam a implementação e as boas práticas que a gente aplica em projeto real. Sem enrolação e sem prometer mágica onde não tem.

A atualização incremental resolve volume, não resolve modelagem ruim#

Antes de configurar qualquer coisa, entenda o que essa funcionalidade faz e o que ela não faz. Ela divide a tabela em partições por período e atualiza só as partições recentes. Isso ataca três dores concretas.

• Tempo de refresh: você lê menos linhas, então termina mais rápido.
• Consumo de memória durante a carga: partições menores pesam menos no serviço.
• Carga na fonte: menos consultas pesadas batendo no banco de origem.

O que ela não faz: não conserta um modelo mal desenhado, não substitui uma boa tabela de datas e não acelera consulta de usuário final (isso é assunto de modelagem e DAX). Se o seu problema é lentidão ao clicar no relatório, incremental refresh não é o remédio. Se o problema é o refresh diário demorando demais, é exatamente aqui que você resolve.

Vale a pena configurar quando o cenário bate com estas condições:

Situação	Atualização incremental ajuda?
Tabela fato com milhões de linhas e histórico longo	Sim, é o caso clássico
Dados que só crescem (append), com pouca alteração no passado	Sim, ideal
Fonte que suporta query folding (SQL, Fabric, Synapse)	Sim, com folding funcionando
Tabela dimensão pequena (produtos, clientes)	Não, não compensa a complexidade
Dados que mudam retroativamente sem controle	Cuidado, precisa de estratégia extra
Fonte que não faz folding (muitos Excel, pastas)	Evite, o filtro roda na memória e anula o ganho

Você precisa de dois parâmetros e uma coluna de data confiável#

A atualização incremental depende de dois parâmetros especiais, obrigatoriamente chamados RangeStart e RangeEnd, ambos do tipo Data/Hora. Esses nomes não são sugestão, são exigência do Power BI. Eles delimitam a janela de dados que o Power Query enxerga no Desktop e, depois de publicado, o serviço usa esses parâmetros para montar as partições automaticamente.

A lógica é simples: você filtra a coluna de data da tabela para trazer apenas as linhas entre RangeStart e RangeEnd. No Desktop, esse filtro carrega um recorte pequeno, o que já deixa o desenvolvimento leve. Na nuvem, o serviço troca esses valores por baixo dos panos para gerar cada partição de arquivamento e de atualização.

Um pré-requisito honesto: você precisa de uma coluna de data limpa e estável na tabela fato. Se a sua data vem como texto, ou tem fuso bagunçado, ou muda de formato, arrume isso antes. E revise a modelagem geral do projeto, porque incremental refresh sobre um modelo torto só esconde o problema. Se quiser aprofundar boas práticas de modelo, vale ler o guia de modelagem e DAX antes de seguir.

Passo a passo para configurar a atualização incremental#

Vou dividir em etapas objetivas. Faça na ordem, porque cada uma depende da anterior.

Passo 1: crie os parâmetros RangeStart e RangeEnd#

No Power BI Desktop, abra o Transformar dados para entrar no Power Query. Em Gerenciar Parâmetros, crie dois parâmetros novos:

• Nome exato RangeStart, tipo Data/Hora, com um valor atual qualquer no passado, por exemplo 01/01/2024 00:00:00.
• Nome exato RangeEnd, tipo Data/Hora, com um valor atual mais recente, por exemplo 01/02/2024 00:00:00.

Esses valores atuais servem só para o desenvolvimento no Desktop. O serviço vai sobrescrevê-los quando montar as partições.

Passo 2: filtre a tabela fato pela coluna de data#

Selecione a sua tabela fato no Power Query. Clique no filtro da coluna de data e aplique um filtro personalizado do tipo: é posterior ou igual a RangeStart e é anterior a RangeEnd. Repare no detalhe: RangeStart usa maior ou igual, e RangeEnd usa estritamente menor. Isso evita contar a mesma linha de fronteira em duas partições. É um erro clássico usar menor ou igual nos dois lados e duplicar registros na borda.

Confirme que o filtro reduziu a tabela para o recorte esperado. Se você configurou de 01/01 a 01/02, deve ver só janeiro.

Passo 3: verifique o query folding#

Esse passo separa quem ganha performance de quem só complica a vida. Depois de aplicar o filtro, clique com o botão direito no último passo aplicado e veja se Exibir consulta nativa está disponível. Se estiver, o Power Query está empurrando o filtro para a fonte (query folding ativo), e a fonte devolve só as linhas necessárias. É isso que você quer.

Se Exibir consulta nativa estiver acinzentado, o filtro vai rodar na memória depois de baixar tudo, e aí a atualização incremental perde boa parte do sentido. Isso costuma acontecer com fontes de arquivo e com transformações que quebram o folding. Fontes como SQL Server, Azure SQL, Synapse e Fabric costumam foldar bem. Se a sua fonte não folda, considere primeiro resolver a ingestão com uma camada de dados adequada, tema que tratamos em engenharia de dados.

Passo 4: defina a política de atualização incremental#

Feche o Power Query e volte ao modelo. Clique com o botão direito na tabela fato e escolha Atualização incremental. Ative a opção e preencha:

• Arquivar dados a partir de: por quanto tempo manter o histórico. Exemplo, 5 anos.
• Atualizar incrementalmente dados iniciados em: a janela quente que será recarregada. Exemplo, 10 dias ou 1 mês.

O restante são opções avançadas que valem muito a pena:

• Detectar alterações de dados: aponte uma coluna de data de modificação (um LastModified) para o serviço recarregar só partições que realmente mudaram, e não a janela quente inteira.
• Apenas atualizar dias completos: garante partições fechadas e evita dados parciais do dia corrente.

Passo 5: publique e faça o primeiro refresh#

Publique no serviço, dentro de um workspace apropriado. O primeiro refresh é o mais demorado, porque é ele que cria todas as partições históricas de uma vez. Depois desse refresh inicial, as próximas atualizações passam a mexer só na janela quente e ficam rápidas.

Uma dica importante: para modelos muito grandes, o primeiro refresh completo pode estourar limites no Power BI Pro. Nesses casos, capacidade dedicada (Premium ou Fabric) resolve, porque permite operações de partição via XMLA e refresh mais robusto. Se a sua organização está pesando essa decisão, o guia completo de Power BI para empresas ajuda a enquadrar licenciamento e capacidade.

Os erros que mais derrubam a atualização incremental#

Já vi todas essas armadilhas em projeto. Anote para não repetir.

Erro	O que acontece	Como evitar
Nome errado nos parâmetros	A opção de incremental nem aparece	Use exatamente RangeStart e RangeEnd, tipo Data/Hora
Filtro com menor ou igual nos dois lados	Linhas duplicadas na fronteira	>= no RangeStart e < no RangeEnd
Query folding quebrado	Baixa tudo e filtra na memória, sem ganho	Verifique a consulta nativa antes de publicar
Coluna de data instável ou como texto	Partições erradas ou refresh falho	Padronize a data no modelo antes
Republicar do Desktop por cima	O serviço apaga as partições e refaz tudo	Após publicado, evite sobrescrever; use XMLA ou pipelines
Esperar acelerar o relatório	Frustração, o clique continua lento	Incremental acelera o refresh, não a consulta do usuário

O erro de republicação merece destaque. Quando você publica de novo o .pbix do Desktop por cima de um dataset que já tem partições no serviço, o Power BI trata como modelo novo e refaz o primeiro refresh inteiro. Em modelo grande, isso significa horas de reprocessamento sem necessidade. Em ambientes maduros, a promoção de conteúdo passa por deployment pipelines e conexão XMLA, não por publicação manual repetida. Esse cuidado faz parte de uma boa governança de dados.

Boas práticas para não se arrepender depois#

Configurar é fácil. Configurar de um jeito que aguenta produção por anos exige disciplina. Estas são as práticas que a gente aplica.

• Ative Detectar alterações de dados sempre que a fonte tiver uma coluna de modificação. Sem isso, o serviço recarrega a janela quente completa toda vez. Com isso, ele recarrega só o que mudou de fato. A diferença em fonte pesada é enorme.
• Dimensione a janela quente com honestidade. Se seus dados só chegam do dia anterior, uma janela de 10 dias já é folgada. Janela grande demais desperdiça o ganho; pequena demais pode perder atualização de dados que chegam atrasados.
• Cuidado com correção retroativa. Se o seu sistema corrige lançamentos de meses atrás, a janela quente não vai pegar essas mudanças. Nesse cenário, ou você amplia a janela, ou usa Detectar alterações, ou faz um refresh full agendado periódico só para reconciliar.
• Teste o query folding a cada mudança de transformação. Uma etapa nova no Power Query pode quebrar o folding sem aviso e derrubar a performance silenciosamente.
• Monitore o refresh depois de publicado. Acompanhe duração e falhas. Uma atualização incremental bem feita deve manter tempos estáveis; se começar a subir, algo mudou na fonte ou no folding. Estruturar esse acompanhamento é papel de sustentação de BI.
• Documente a política. Quanto de histórico, qual janela quente, qual coluna de data, se usa Detectar alterações. Quem assumir o modelo depois vai agradecer.

Perguntas frequentes#

A atualização incremental funciona no Power BI Pro ou só no Premium?

Funciona no Pro, mas com limites. O primeiro refresh de um modelo muito grande pode esbarrar nos tempos e no tamanho permitidos no Pro. Capacidade dedicada, seja Premium por capacidade ou Fabric, dá mais robustez, permite operações de partição via XMLA e lida melhor com o refresh inicial pesado. Para volumes moderados, o Pro atende bem.

A atualização incremental deixa o meu relatório mais rápido para o usuário?

Não. Ela acelera o processo de atualização dos dados (o refresh), não a experiência de clicar e navegar no relatório. A velocidade de consulta depende de modelagem, star schema e DAX bem escrito. Se o clique está lento, o caminho é revisar o modelo e as medidas, não o incremental.

Preciso mesmo de query folding para usar incremental?

Tecnicamente você consegue configurar sem folding, mas perde o principal benefício. Sem folding, o Power Query baixa a tabela inteira e só depois aplica o filtro na memória, ou seja, a fonte continua sendo lida por completo. O ganho real de tempo e de carga na origem só aparece quando o folding empurra o filtro para o banco. Sempre verifique a consulta nativa.

O que acontece se eu republicar o modelo do Desktop?

O serviço trata a publicação como um modelo novo e descarta as partições existentes, refazendo o primeiro refresh completo. Em modelo grande, isso custa caro em tempo. Por isso, depois que o modelo com incremental está publicado, a recomendação é promover mudanças via deployment pipelines ou operações XMLA, evitando sobrescrever com o .pbix do Desktop.

Como lidar com dados que mudam retroativamente?

Se lançamentos antigos são corrigidos, a janela quente padrão não captura essas mudanças. As opções são: ampliar a janela de atualização para cobrir o período que sofre alteração, ativar Detectar alterações de dados apontando uma coluna de modificação, ou agendar um refresh completo periódico para reconciliar o histórico. A escolha depende de quão para trás as correções chegam.

Qual coluna de data devo usar para particionar?

Use a data que representa o evento do negócio e que não muda depois de gravada, tipicamente a data da transação ou do documento. Evite datas que possam ser reescritas, porque isso bagunça as partições. A coluna precisa estar em tipo Data/Hora, limpa e consistente, antes de você aplicar o filtro com RangeStart e RangeEnd.

Conclusão#

Atualização incremental é uma das configurações de maior retorno em modelos grandes: pouco esforço, ganho direto em tempo de refresh, memória e carga na fonte. Mas ela não perdoa descuido. Nome de parâmetro tem que ser exato, o filtro precisa respeitar a fronteira, o query folding tem que estar de pé e a coluna de data precisa ser confiável. Acerte esses quatro pontos e o resto flui.

Se o seu ambiente tem vários modelos pesados, refresh instável ou você não sabe se a arquitetura de dados aguenta o crescimento, faz sentido revisar isso com quem já implementou em escala. Fale com a gente e a equipe da Fynx ajuda a diagnosticar e a deixar seus modelos rápidos e sustentáveis.