Import vs DirectQuery vs Direct Lake no Power BI

A decisão de armazenamento define a performance antes de qualquer medida DAX#

A maioria dos relatórios lentos não fica lenta por causa de uma medida mal escrita. Fica lenta porque escolheram o modo de armazenamento errado lá no começo, e ninguém voltou para revisar. A discussão Import vs DirectQuery Power BI parece um detalhe técnico que só o desenvolvedor precisa entender, mas ela decide se o relatório abre em um segundo ou em quinze, se os dados são de agora ou de ontem, e quanto a fonte de origem vai sofrer toda vez que alguém clicar em um filtro. Com o Microsoft Fabric, entrou um terceiro modo na conversa, o Direct Lake, que promete juntar o melhor dos dois mundos. Este guia explica os três sem torcer para nenhum, e mostra em que cenário cada um faz sentido.

O modo Import carrega os dados para dentro do modelo e consulta na memória#

No modo Import, o Power BI copia os dados da origem para dentro do próprio arquivo, comprimidos pelo motor VertiPaq. O VertiPaq é um mecanismo colunar em memória: ele guarda cada coluna separada e comprime pela cardinalidade, ou seja, quanto menos valores distintos uma coluna tem, menor ela fica. Uma coluna de status com cinco valores ocupa quase nada; uma coluna de data e hora com segundos ocupa muito. Por isso a modelagem importa tanto no Import.

A grande vantagem é a velocidade. Como os dados estão na memória e comprimidos, as consultas DAX voam. É o modo que entrega a melhor experiência interativa, com toda a linguagem DAX disponível e sem limitações de recurso. O custo é que os dados não são ao vivo: eles refletem o último refresh. Se o relatório atualiza de madrugada, durante o dia ele mostra a foto da noite anterior. E o tamanho do modelo fica limitado pela memória da capacidade ou pela licença, então volumes muito grandes exigem cuidado.

Import é a escolha padrão para a maioria dos relatórios corporativos: vendas, financeiro, operações, indicadores gerenciais. Onde atualizar algumas vezes ao dia é suficiente, ele quase sempre é a resposta certa.

O modo DirectQuery mantém os dados na origem e consulta em tempo real#

No DirectQuery, o Power BI não copia nada. Ele guarda só a estrutura do modelo e, a cada interação do usuário, gera uma consulta e manda para a fonte original, seja um banco SQL, um data warehouse ou outra base. O resultado volta e é exibido.

A vantagem óbvia é o dado sempre atual: o relatório mostra o que está na origem naquele instante. Também não há limite de memória do modelo, porque os dados ficam na fonte. Isso o torna atraente para bases enormes ou para casos que exigem frescor absoluto, como monitoramento operacional.

Os custos são reais e é honesto colocá-los na mesa. Cada clique vira uma consulta na origem, então a performance depende do banco e da rede, e costuma ser mais lenta que o Import. Parte da linguagem DAX fica limitada ou é traduzida para SQL de forma menos eficiente. E há a carga na fonte: se muitos usuários abrem o relatório ao mesmo tempo, o banco de produção sente. DirectQuery pede uma origem bem indexada e, de preferência, dedicada a analytics.

O modo Direct Lake lê direto do OneLake sem importar nem consultar a origem#

O Direct Lake é o modo que chegou com o Microsoft Fabric e muda a equação. Em vez de importar os dados ou de consultar um banco transacional a cada clique, ele lê diretamente os arquivos em formato Delta e Parquet que estão no OneLake, o data lake unificado do Fabric. Não há um processo de refresh copiando dados para dentro do modelo, e não há uma consulta indo para um banco de origem toda vez.

Na prática, ele busca entregar performance perto do Import sem o passo de importação e sem a defasagem do refresh, porque lê a mesma cópia dos dados que já está no lake. Quando encontra um cenário que não consegue resolver diretamente, ele pode cair para DirectQuery de forma transparente, o chamado fallback. É um modo poderoso, mas com um pré-requisito claro: ele vive dentro do Fabric e exige capacidade Fabric, além de que os dados precisam estar organizados no OneLake em formato adequado. Não é algo que você liga em qualquer relatório antigo sem uma plataforma de dados por trás.

Uma tabela lado a lado deixa a escolha mais concreta#

Critério	Import	DirectQuery	Direct Lake
Onde ficam os dados	Copiados para o modelo (VertiPaq)	Na origem, consultados a cada interação	No OneLake, lidos direto em Delta/Parquet
Atualidade	Última carga (refresh)	Tempo real	Próximo do tempo real, sem refresh de cópia
Performance de consulta	Melhor	Depende da origem, geralmente menor	Próxima do Import
Carga na fonte	Só no refresh	A cada clique do usuário	Baixa, lê o lake
Cobertura de DAX	Completa	Limitada em partes	Ampla, com fallback quando necessário
Pré-requisito	Nenhum especial	Origem robusta e indexada	Capacidade Fabric e dados no OneLake
Melhor para	Relatórios gerenciais no geral	Frescor absoluto e bases muito grandes	Plataforma de dados moderna no Fabric

O modelo composto permite misturar Import e DirectQuery na mesma solução#

Nem sempre a resposta é um modo só. O modelo composto, ou composite model, deixa você combinar tabelas em Import com tabelas em DirectQuery no mesmo modelo. Um padrão comum é manter as dimensões e o histórico consolidado em Import, para velocidade, e deixar a tabela de fatos mais recente ou mais volumosa em DirectQuery, para frescor. É uma ferramenta de arquitetura útil, mas que exige cuidado com relacionamentos e com a experiência do usuário, porque parte do relatório herda as limitações do DirectQuery.

Como escolher o modo certo depende do cenário, não da moda#

A pergunta a fazer não é qual modo é o melhor, e sim qual problema você está resolvendo. Se o requisito é um relatório gerencial rápido, com atualização algumas vezes ao dia, o Import resolve com folga e é o caminho mais simples. Se a exigência é ver o dado exatamente como está na origem, agora, e a base é robusta o suficiente para aguentar as consultas, o DirectQuery se justifica. Se a empresa já está construindo uma plataforma moderna no Fabric, com dados organizados no OneLake, o Direct Lake oferece um caminho que une performance e atualidade sem o custo do refresh.

Na maioria dos projetos que acompanhamos, a decisão vem do requisito de negócio (com que frequência o dado precisa mudar) e da maturidade da plataforma (existe um lake no Fabric ou não). Definir isso antes de modelar evita a retrabalho mais caro de todos, que é migrar de modo depois que o relatório já está em produção. Se quiser aprofundar a base do modelo, vale ver o guia completo de Power BI para empresas e conhecer nossos serviços de Power BI.

Perguntas frequentes#

Direct Lake substitui o Import? Não substitui em todo lugar. O Direct Lake é excelente quando a empresa já tem uma plataforma no Fabric com dados no OneLake. Fora desse contexto, o Import continua sendo a escolha mais simples e madura para a maioria dos relatórios.

DirectQuery é sempre mais lento que Import? Na prática, quase sempre, porque cada interação gera uma consulta na origem em vez de ler dados já comprimidos na memória. A diferença pode ser pequena com uma origem muito bem preparada, mas o Import parte na frente em performance.

Posso mudar de Import para DirectQuery depois? É possível, mas não é trivial. Trocar o modo pode exigir revisar medidas, relacionamentos e a própria origem. Por isso vale decidir o modo certo no início, olhando o requisito de atualidade e o volume de dados.

Direct Lake precisa de refresh? Ele não faz a cópia de dados que o Import faz, porque lê direto os arquivos do OneLake. O que mantém tudo atualizado é o processo que grava os dados no lake, então o cuidado se desloca para o pipeline de dados.

O que é fallback no Direct Lake? É quando o Direct Lake encontra um cenário que não consegue resolver lendo o lake diretamente e, de forma transparente, passa a usar DirectQuery para aquela consulta. Entender quando isso acontece ajuda a manter a performance previsível.

Qual modo consome menos a base de produção? O Import só toca a origem no momento do refresh, então protege a base de produção durante o dia. O DirectQuery é o que mais pesa, porque consulta a cada clique. O Direct Lake lê o lake, não o banco transacional, então também poupa a produção.

Comece pela pergunta certa#

Antes de abrir o Power BI, defina com que frequência o dado precisa mudar e onde ele mora. A resposta a essas duas perguntas aponta o modo quase sozinha. Se quiser ajuda para desenhar essa arquitetura sem retrabalho, fale com a gente.