Direct Lake no Power BI: velocidade sem cópia

Você não deveria ter que escolher entre dado rápido e dado fresco#

Todo mundo que trabalha com Power BI sério já viveu esse dilema. Ou você importa os dados para dentro do modelo e ganha performance de sobra, mas paga com um refresh pesado que roda de madrugada e deixa o relatório sempre algumas horas atrasado, ou você usa DirectQuery para ter o dado do minuto, e assiste os visuais engasgarem porque cada clique vira uma consulta SQL enviada para a fonte. É um trade-off que já foi tratado como lei da natureza no BI. O Direct Lake no Power BI, o modo de armazenamento que a Microsoft introduziu junto com o Fabric, existe para quebrar essa falsa escolha.

A promessa é ousada e, quando os requisitos batem, ela se cumpre: velocidade próxima do Import com dado atualizado, sem manter uma segunda cópia dentro do modelo. Neste artigo eu explico como o Direct Lake funciona por dentro, o que ele exige para rodar, o que acontece no fallback para DirectQuery e onde estão os limites que ninguém coloca no slide de vendas. É um texto para quem vai decidir arquitetura.

O Direct Lake lê o Delta Parquet direto do OneLake#

Para entender o Direct Lake, é preciso entender o que ele não faz. Ele não importa os dados como o modo Import e não traduz cada consulta para SQL como o DirectQuery. Ele faz uma terceira coisa: lê os arquivos Delta Parquet que já estão gravados no OneLake e carrega as colunas necessárias diretamente na memória, sob demanda, no formato que o motor do Power BI já sabe processar rápido.

Isso é possível por um detalhe técnico que muda tudo. O formato Parquet é colunar e comprimido, e o motor VertiPaq (o mesmo que sustenta o modo Import há anos) também trabalha com colunas comprimidas na memória. Os dois mundos são próximos o suficiente para que o Fabric transponha os dados do Delta Parquet para as estruturas de memória do VertiPaq sem um processo de importação tradicional. Quando um visual pede a coluna de faturamento, o Direct Lake busca aquela coluna no OneLake, carrega na memória e responde. Nas próximas consultas que usam a mesma coluna, ela já está residente e a resposta é imediata.

O termo técnico para esse comportamento é transcodificação sob demanda. Só as colunas efetivamente usadas pelos visuais sobem para a memória, e só quando são pedidas. Você não paga o custo de carregar o modelo inteiro de antemão, como no refresh do Import, nem de buscar tudo na fonte a cada interação, como no DirectQuery. É essa mecânica que produz a sensação de Import com o frescor de dado do DirectQuery.

Vale fixar a base: o Direct Lake vive dentro do Microsoft Fabric e depende do OneLake como camada de armazenamento. Se você ainda está entendendo o ecossistema em volta, o nosso guia sobre o que é o Microsoft Fabric e quando vale a pena dá o contexto de plataforma que sustenta tudo o que vem a seguir.

Import, DirectQuery e Direct Lake resolvem o mesmo problema por caminhos opostos#

A melhor forma de posicionar o Direct Lake é lado a lado com os dois modos que ele quer substituir em boa parte dos cenários. Cada um faz uma aposta diferente sobre onde o dado mora na hora da consulta.

Característica	Import	DirectQuery	Direct Lake
Onde o dado é lido	Cópia na memória do modelo	Fonte original, a cada consulta	Delta Parquet no OneLake, sob demanda
Precisa de refresh agendado	Sim, processo pesado	Não	Não, reflete o Delta atualizado
Frescor do dado	Do último refresh	Tempo quase real	Do último commit no Delta
Velocidade típica de consulta	Alta	Variável, depende da fonte	Alta, próxima do Import
Duplicação de dados	Sim, cópia completa	Não	Não
Depende de capacidade Fabric	Não	Não	Sim

Leia a tabela com calma, porque cada linha esconde uma decisão de projeto. A linha de refresh é a que costuma vender o Direct Lake sozinha: sumir com a janela de processamento noturno resolve uma dor operacional real em modelos grandes que levam horas para atualizar. A linha de frescor merece uma ressalva honesta: o Direct Lake reflete o que está gravado no Delta, então o dado só é tão fresco quanto o seu pipeline que grava no OneLake. Se a engenharia carrega o lakehouse uma vez por hora, o relatório é atualizado de hora em hora. Direct Lake não é mágica de tempo real, é a eliminação da cópia intermediária entre o lake e o modelo.

O Direct Lake no Power BI tem requisitos que não são negociáveis#

Aqui a conversa de arquitetura fica séria. O Direct Lake não é um botão que você liga em qualquer relatório antigo. Ele impõe condições, e conhecê-las antes evita descobri-las no meio da migração.

• Capacidade Fabric. O Direct Lake só roda sobre uma capacidade Fabric. Não existe Direct Lake em Power BI Pro puro sem Fabric por trás. Isso tem implicação direta de custo e de licenciamento, então entra na conta antes de qualquer decisão.
• Dados em Delta Parquet no OneLake. A fonte tem que ser tabelas Delta em um lakehouse ou warehouse do Fabric. Se seus dados estão em um SQL Server on-premises ou num Snowflake, eles precisam primeiro ser materializados como Delta no OneLake. Ou seja, o trabalho de engenharia não desaparece, ele muda de lugar.
• Modelo semântico construído sobre essas tabelas. O modelo do Power BI aponta para as tabelas Delta, não para uma cópia importada. As relações, medidas e hierarquias continuam existindo normalmente, mas o armazenamento das tabelas é definido como Direct Lake.
• Layout dos arquivos importa. Tabelas Delta muito fragmentadas, com excesso de arquivos pequenos, degradam a leitura. Manutenção do lakehouse, com operações como compactação e ordenação, deixa de ser detalhe e vira parte da performance do relatório.

Repare no terceiro e no quarto ponto: o Direct Lake tira a responsabilidade da camada de importação e joga parte dela para a camada de engenharia de dados. Um bom lakehouse, bem particionado e bem mantido, é pré-requisito para um bom Direct Lake. Não é coincidência que os projetos que dão certo com Direct Lake costumam ser os que já levavam a engenharia de dados a sério antes de chegar no BI.

O fallback para DirectQuery é a rede de segurança e o ponto cego#

Nenhum modo é perfeito, e o Direct Lake tem um mecanismo de escape que você precisa entender porque ele afeta performance sem avisar em letras garrafais. Em certas situações, o Direct Lake não consegue responder uma consulta lendo direto do OneLake e cai automaticamente para DirectQuery contra o endpoint SQL da fonte. Isso se chama fallback.

O fallback é elegante porque garante que a consulta sempre é respondida, o relatório não quebra. O problema é que a consulta que caiu herda o comportamento do DirectQuery e pode ficar mais lenta, porque agora vira uma tradução para SQL enviada à fonte. Se o fallback acontece com frequência, a sensação de velocidade de Import evapora nos visuais afetados, e o diagnóstico não é óbvio para quem não sabe que o mecanismo existe.

Situação	O que costuma acontecer
Consulta simples sobre tabela Delta bem formada	Servida pelo Direct Lake, rápida
Recurso não suportado pelo modo em uma consulta específica	Cai para DirectQuery no endpoint SQL
Volume de dados acima do que a capacidade comporta na memória	Pode acionar fallback ou limites de guardrail
Uso de views ou objetos que o Direct Lake não lê nativamente	Tende a resolver via DirectQuery

A leitura de consultoria aqui é direta: o fallback é uma rede de segurança que você quer que exista, mas não é um lugar onde você quer morar. Monitorar quantas consultas caem para DirectQuery é parte da operação de um modelo Direct Lake saudável. Quando o fallback vira regra e não exceção, ou a modelagem precisa de ajuste, ou a capacidade está subdimensionada, ou o layout do lakehouse pede manutenção.

O VertiPaq continua mandando na compressão#

Um mal-entendido comum é achar que o Direct Lake aposenta tudo o que se sabia sobre modelagem tabular. Não aposenta. O motor de consulta ainda é o VertiPaq, e o VertiPaq comprime dados por cardinalidade. Colunas com muitos valores distintos, como identificadores únicos, timestamps com precisão de segundo ou textos livres, comprimem mal e ocupam mais memória, exatamente como sempre ocuparam no modo Import.

Isso significa que as boas práticas de modelagem não foram revogadas pelo Direct Lake, elas continuam valendo. Reduzir a cardinalidade onde é possível, separar data e hora em colunas distintas, evitar trazer colunas que ninguém usa, projetar um esquema estrela limpo: tudo isso segue impactando quanto de memória cada coluna consome. Se você quer aprofundar esse lado, vale revisar as boas práticas de modelagem e DAX no Power BI, porque elas se aplicam ao Direct Lake quase na íntegra.

O ganho do Direct Lake está em eliminar a cópia e o refresh, não em perdoar modelagem preguiçosa. Um modelo mal desenhado consome mais memória da capacidade e empurra mais consultas para o fallback. A disciplina de modelagem que já era importante no Import fica ainda mais visível quando o custo de memória é compartilhado com a capacidade Fabric inteira.

Quando o Direct Lake vale e quando ele ainda não é a resposta#

Sendo honesto, o Direct Lake brilha em um perfil claro de cenário: empresa que já está no Fabric ou tem plano firme de estar, com dados centralizados no OneLake em Delta Parquet, modelos grandes cujo refresh do Import já incomoda, e necessidade de dado mais fresco sem pagar o preço do DirectQuery em cada clique. Nesse perfil, ele entrega o que promete e simplifica a arquitetura de forma concreta.

Ele ainda não é a resposta óbvia quando a empresa não tem capacidade Fabric nem pretende adquirir, quando os dados vivem fora do OneLake sem projeto de consolidação, ou quando o modelo é pequeno e o refresh do Import roda em minutos sem incomodar ninguém. Nesses casos, migrar para Direct Lake é resolver um problema que você não tem e criar uma dependência de plataforma que custa dinheiro. Consultoria boa às vezes é dizer que a ferramenta nova não é para agora.

Se a sua dúvida é justamente essa, se o Direct Lake encaixa no seu momento ou se o caminho mais sensato é evoluir o Power BI sobre a arquitetura que você já tem, esse é um diagnóstico que fazemos com frequência e que rende decisões bem mais baratas do que uma migração feita no impulso.

Perguntas frequentes#

O Direct Lake substitui o Import de vez? Não para todo mundo. Ele substitui o Import com vantagem em modelos grandes sobre dados que já estão em Delta Parquet no OneLake, dentro de uma capacidade Fabric. Para modelos pequenos, fora do Fabric ou com fontes que não estão no OneLake, o Import continua sendo uma escolha perfeitamente válida e mais simples.

Direct Lake é tempo real? Não exatamente. Ele reflete o estado atual das tabelas Delta no OneLake, então o dado é tão fresco quanto o último commit gravado pelo seu pipeline. Se a engenharia grava no lakehouse de hora em hora, o relatório acompanha de hora em hora. O que ele elimina é a defasagem extra do refresh do modelo, não a cadência do seu pipeline de dados.

Por que meu relatório Direct Lake às vezes fica lento? A causa mais comum é o fallback para DirectQuery. Quando uma consulta usa algo que o Direct Lake não serve nativamente, ela é resolvida via SQL na fonte e herda a lentidão do DirectQuery. Vale monitorar a frequência de fallback e revisar modelagem, layout do lakehouse e dimensionamento da capacidade quando ele passa a ser regra.

Preciso de licença especial para usar Direct Lake? Você precisa de uma capacidade Fabric. O Direct Lake não roda em Power BI Pro puro sem Fabric por trás. Isso entra no cálculo de custo total, porque a capacidade tem um custo próprio que precisa ser dimensionado conforme o volume de dados e a concorrência de usuários.

A modelagem muda muito em relação ao Import? Menos do que se imagina. As relações, medidas em DAX e hierarquias funcionam como sempre, e o VertiPaq segue comprimindo por cardinalidade. A diferença principal é que o armazenamento das tabelas aponta para o Delta no OneLake em vez de uma cópia importada, e a manutenção do lakehouse passa a influenciar diretamente a performance do relatório.

Meus dados fora do Fabric podem usar Direct Lake? Não diretamente. Para o Direct Lake ler, os dados precisam estar materializados como tabelas Delta Parquet no OneLake. Fontes como SQL Server, Snowflake ou APIs precisam primeiro ser levadas ao OneLake por um pipeline. Esse trabalho de engenharia não some, ele muda de lugar.

Em resumo#

O Direct Lake no Power BI é a resposta da Microsoft para um trade-off que o mercado tratava como permanente: velocidade de Import com dado fresco, sem manter uma segunda cópia. Ele cumpre a promessa quando os requisitos batem, capacidade Fabric, dados em Delta Parquet no OneLake e um lakehouse bem cuidado, e cobra o preço em dependência de plataforma e disciplina de engenharia. Não é bala de prata, é uma ferramenta forte para o cenário certo. Se quer saber se esse é o seu cenário antes de investir na migração, fale com a gente e avaliamos juntos com base na sua arquitetura real.