(+351) 21 24 10006  ·  info@bconcepts.pt
Carnaxide, Lisboa
DirectQuery vs Import no Power BI: quando usar cada um
Power BI

DirectQuery vs Import no Power BI: quando usar cada um

João Barros 05/07/2026 9 min

Quando começas um relatório no Power BI, uma das primeiras decisões — muitas vezes tomada sem se pensar nela — é como o modelo vai buscar os dados: trazer uma cópia para dentro do ficheiro (Import) ou consultar a fonte de cada vez que alguém abre um visual (DirectQuery). Parece um detalhe técnico, mas condiciona o desempenho, a frescura dos dados, o custo e até que funções de DAX vais poder usar.

A escolha errada nota-se depressa: relatórios que demoram segundos a responder a cada clique, atualizações que falham a meio da noite, ou números que nunca estão suficientemente atualizados para quem os consome. A boa notícia é que a decisão segue regras razoavelmente claras, desde que percebas o que cada modo faz por baixo do capô.

Neste artigo comparamos os dois modos de armazenamento sem romantismos: como funcionam, onde cada um brilha, que limites impõem e como combiná-los quando nenhum dos dois, sozinho, chega. No fim, ficas com um critério simples para decidir caso a caso.

O que muda entre Import e DirectQuery

A diferença essencial é onde vivem os dados no momento em que o relatório é consultado. No modo Import, o Power BI lê a fonte, comprime os dados e guarda-os dentro do modelo. A partir daí, todos os cálculos correm sobre essa cópia local. No DirectQuery, não há cópia: cada visual gera uma consulta que é enviada à fonte (uma base de dados SQL, um data warehouse, etc.) e o resultado volta em tempo real.

DirectQuery vs Import no Power BI: quando usar cada um

Essa distinção explica quase tudo o resto. O Import é rápido porque não depende da fonte a cada interação, mas fica com uma fotografia dos dados que só muda quando há uma atualização. O DirectQuery está sempre a par da fonte, mas paga esse frescor com latência e com uma dependência total do desempenho do sistema de origem.

Import: dados em memória com o motor VertiPaq

No modo Import, os dados são carregados para o VertiPaq, o motor colunar em memória do Power BI. O VertiPaq comprime as colunas de forma muito eficiente — é comum ver tabelas de dezenas de milhões de linhas ocuparem uma fração do tamanho original — e responde a consultas analíticas a uma velocidade difícil de igualar.

Essa é a razão pela qual o Import é a escolha por defeito para a maioria dos relatórios. Tens acesso à linguagem DAX completa, a agregações rápidas, e a interação fluida com segmentações e filtros. O preço a pagar é que o modelo tem de caber em memória e que os dados só refletem a fonte até à última atualização. Os limites de tamanho do modelo dependem da licença e da capacidade — o que é confortável num Power BI Premium pode não caber num plano mais modesto.

DirectQuery: consultar a fonte em tempo real

No DirectQuery, o modelo guarda apenas os metadados — a estrutura das tabelas e as relações — e não os dados em si. Cada vez que um utilizador interage com um visual, o Power BI traduz a operação numa consulta à fonte. Isto tem uma vantagem evidente: os números estão sempre tão atualizados quanto a base de dados subjacente.

É a abordagem indicada quando os dados mudam ao minuto (por exemplo, stock ou operações), quando o volume é tão grande que não faria sentido importá-lo, ou quando há requisitos de governação que exigem que os dados não saiam da fonte. Em troca, ficas dependente da rapidez dessa fonte: se a base de dados estiver mal indexada ou sobrecarregada, o relatório herda essa lentidão.

Desempenho: porque o Import quase sempre ganha

Em igualdade de circunstâncias, o Import é mais rápido. As consultas correm contra o VertiPaq, em memória, sem saltos de rede e sem competir com a carga transacional da fonte. No DirectQuery, cada interação é uma ida e volta à base de dados, e várias visualizações no mesmo separador podem disparar várias consultas em simultâneo.

Isto não significa que o DirectQuery seja lento por natureza. Com uma fonte bem otimizada — índices adequados, tabelas de agregação, um data warehouse desenhado para leitura analítica — pode ter um desempenho perfeitamente aceitável. Mas exige trabalho de engenharia do lado da fonte que o Import, em grande medida, dispensa.

Atualização e frescura dos dados

Aqui os papéis invertem-se. No Import, a frescura depende da frequência de atualização que configuras — de hora a hora, algumas vezes por dia, ou o máximo que a tua licença permitir. Entre atualizações, o relatório mostra a última fotografia. Para muitas decisões de gestão, isso é mais do que suficiente.

No DirectQuery, os dados estão sempre atualizados por construção, porque são lidos da fonte no momento. Se a tua pergunta é «quantas unidades tenho em armazém agora?», o DirectQuery responde com a verdade do instante; o Import responde com a verdade da última atualização. Escolher entre um e outro é, no fundo, decidir quanta desatualização o negócio tolera.

Limites e restrições de cada modo

O DirectQuery traz restrições que convém conhecer antes de decidir. Nem todas as funções de DAX estão disponíveis, algumas transformações no Power Query não são suportadas, e existe um limite prático no volume que cada consulta pode devolver. Por predefinição, uma consulta em DirectQuery falha se um resultado intermédio ultrapassar cerca de um milhão de linhas — um travão pensado para evitar consultas que consumiriam memória e tempo em excesso (em capacidades Premium este limite pode ser aumentado).

O Import tem outro tipo de limite: o modelo inteiro tem de caber nos limites de tamanho da tua capacidade. Modelos muito grandes obrigam a estratégias como a atualização incremental, agregações ou a redução do detalhe. São problemas diferentes, mas ambos moldam a decisão.

Modelos compostos e modo Dual: o melhor dos dois

Felizmente, não é obrigatório escolher um modo para o modelo inteiro. Os modelos compostos permitem que algumas tabelas estejam em Import e outras em DirectQuery no mesmo relatório. O modo Dual vai mais longe: uma tabela pode comportar-se como Import ou como DirectQuery consoante a consulta, o que é especialmente útil em tabelas de dimensão partilhadas.

O padrão mais comum combina uma tabela de factos enorme em DirectQuery com dimensões pequenas em Import (ou Dual), muitas vezes com tabelas de agregação por cima para responder de imediato às perguntas mais frequentes. É uma forma de ter frescura onde é preciso e velocidade onde é possível.

Mini-caso: relatórios lentos numa empresa de retalho

Imagina uma empresa de retalho com cerca de 200 lojas que montou um painel de vendas em DirectQuery diretamente sobre a base de dados transacional. Ao início do mês, quando todos abriam o relatório ao mesmo tempo, cada clique demorava seis a oito segundos e a base de dados operacional sentia o peso das consultas analíticas a competir com as vendas.

A equipa reconfigurou o modelo: passou os dados históricos de vendas para Import, com atualização de hora a hora, e manteve em DirectQuery apenas a tabela de stock em tempo real, através de um modelo composto. O tempo de resposta dos visuais históricos caiu para menos de um segundo, a carga sobre a base de dados operacional desapareceu, e o indicador de stock continuou a mostrar o valor do momento. Nada de mágico — apenas o modo certo para cada tabela.

Custo, manutenção e o fator humano

Há um custo que raramente entra na conta: o de manutenção. Um modelo Import bem desenhado tende a ser mais previsível — atualiza, funciona, e a maior parte dos problemas resolve-se dentro do Power BI. Um modelo DirectQuery espalha a responsabilidade: o desempenho do relatório passa a depender de quem gere a base de dados, dos índices, da carga concorrente e da rede. Quando algo corre mal, a investigação envolve mais gente e mais camadas.

Isto não é argumento contra o DirectQuery — é um lembrete de que a escolha do modo de armazenamento também é uma escolha organizacional. Se não tens quem afine a fonte, um DirectQuery mal suportado transforma-se rapidamente em queixas de utilizadores. Se, pelo contrário, tens uma equipa de dados sólida e um warehouse cuidado, o custo de manutenção do DirectQuery deixa de ser um obstáculo.

Como escolher: um guia rápido

Como regra geral, começa por Import e só te afastes dele quando houver uma razão concreta. Estes são os sinais que costumam justificar DirectQuery (total ou parcial):

  • Frescura ao minuto: o negócio precisa de ver os dados praticamente em tempo real, e uma fotografia de hora a hora não chega.
  • Volume incomportável: a fonte tem tantos dados que importá-los não é viável dentro dos limites da tua capacidade.
  • Requisitos de governação: por política ou regulação, os dados não podem ser copiados para fora do sistema de origem.
  • Fonte já otimizada para leitura: tens um data warehouse rápido, com agregações e índices, pronto para aguentar consultas analíticas.

Se nenhum destes pontos se aplica, o Import quase de certeza dá-te melhor experiência com menos esforço. E quando um só modo não resolve, lembra-te de que o modelo composto existe precisamente para esses casos intermédios.

Na prática

Import e DirectQuery não são rivais a eliminar, mas ferramentas para contextos diferentes. O Import entrega velocidade e a linguagem DAX completa à custa de trabalhar com uma fotografia dos dados; o DirectQuery entrega frescura permanente à custa de latência e de restrições. A maturidade está em saber quando cada um é adequado — e em usar modelos compostos quando a resposta certa é «depende da tabela».

Antes de decidir, faz três perguntas simples: com que frequência os dados mudam, que volume estamos a falar, e quão rápida é a fonte. As respostas quase sempre apontam para o modo certo. Escolhe com intenção, não por hábito, e o teu relatório vai agradecer — em cada clique.

← Voltar aos insights
Vamos conversar?

Pronto para transformar os seus dados?

Marque uma reunião gratuita de 30 minutos e descubra como podemos ajudar a sua equipa a tomar melhores decisões.

Agendar Reunião Gratuita
bConcepts