Direct Lake no Power BI: o modo de storage que não é Import nem DirectQuery
Durante anos, modelar um relatório no Power BI significou escolher entre dois extremos: Import, que copia os dados pro arquivo e fica rápido mas desatualizado até a próxima atualização; ou DirectQuery, que consulta a fonte em tempo real mas paga o preço em performance. O Microsoft Fabric introduziu um terceiro caminho, pensado especificamente pra quem já guarda dados no OneLake: o Direct Lake.
- Direct Lake lê os arquivos Parquet do OneLake diretamente para a memória do mecanismo analítico, sem duplicar os dados num modelo importado.
- Diferente do DirectQuery, não gera uma consulta na fonte a cada interação — os dados já estão carregados como colunas em memória.
- Funciona com tabelas de Lakehouse e Warehouse do Fabric; fora desse cenário, o modelo volta a se comportar como Import ou DirectQuery.
- É o modo padrão de itens como o Lakehouse default semantic model no Fabric.
Por que Import e DirectQuery não bastavam
Import serve bem quando o volume cabe na memória e a atualização periódica é aceitável — mas cada atualização reprocessa e duplica dados que já existem em algum lugar. DirectQuery resolve o problema do dado sempre atual, só que troca velocidade por consultas na fonte a cada clique de segmentação, o que castiga relatórios com muitas interações. Quando a fonte já é o próprio OneLake do Fabric, os dois modos ficam redundantes: por que copiar (Import) ou reconsultar (DirectQuery) um arquivo que o mecanismo analítico já pode enxergar direto?
Como o Direct Lake funciona na prática
As tabelas de um Lakehouse ou Warehouse do Fabric ficam salvas no OneLake em formato Delta Parquet. O Direct Lake permite que o mecanismo de análise do Power BI carregue essas colunas Parquet diretamente para a memória, sem passar por um pipeline de importação tradicional e sem reescrever os dados num formato proprietário. Na prática, o relatório se comporta com a velocidade de um modelo Import, mas reflete mudanças na tabela de origem muito mais perto do tempo real, porque não existe uma cópia intermediária desatualizando.
Isso não significa que o Direct Lake seja sempre superior — ele depende de as tabelas estarem no OneLake, dentro do Fabric. Fora desse cenário (uma fonte SQL Server tradicional, por exemplo), a escolha continua sendo entre Import e DirectQuery.
Quando faz sentido usar Direct Lake
Vale considerar Direct Lake quando o pipeline de dados já termina num Lakehouse ou Warehouse do Fabric e o relatório precisa refletir mudanças com baixa latência, sem pagar o custo de performance do DirectQuery tradicional. É o cenário mais comum de quem já centralizou a engenharia de dados no Fabric e quer que o Power BI consuma esse resultado sem uma etapa extra de importação.
Quer aprender isso (e muito mais) com prática guiada?
O curso completo de Power BI da TECH SANTOS BR cobre Excel aplicado, modelagem de dados, Power Query e DAX — do zero até dashboards publicados de verdade.
Perguntas frequentes
Direct Lake substitui o Import?
Só quando os dados já estão num Lakehouse ou Warehouse do Fabric. Fora desse cenário, Import continua sendo a opção padrão.
Direct Lake é mais lento que Import?
Não — os dados também ficam carregados em memória como colunas, então a experiência de navegação é comparável à de um modelo Import.
Preciso reconfigurar atualização de dados com Direct Lake?
Não da mesma forma que no Import. O modelo lê a versão mais recente da tabela do OneLake, sem um agendamento de atualização tradicional.
Direct Lake funciona fora do Microsoft Fabric?
Não. Depende das tabelas estarem armazenadas no OneLake, dentro de um Lakehouse ou Warehouse do Fabric.