Power Query: como conectar em um SQL Server

Conectar ao banco parece o passo fácil, até a atualização quebrar no serviço#

Quase todo projeto de Power BI começa no mesmo ponto: o dado que interessa está num SQL Server, e alguém precisa trazer aquilo para dentro do relatório. Fazer Power Query conectar em um SQL Server é, de fato, um dos passos mais simples da ferramenta. Você abre o conector, digita o nome do servidor, escolhe as tabelas e pronto. O relatório aparece na tela em minutos e todo mundo fica feliz.

O problema quase nunca está na primeira conexão. Ele aparece depois: a atualização agendada falha no Power BI Service, o relatório fica lento porque puxou o banco inteiro, ou o time percebe que uma transformação inocente derrubou o query folding e agora o SQL Server nem é mais usado de verdade. Neste artigo vou mostrar o caminho do jeito que a gente faz em projeto real na Fynx: o conector certo, a decisão entre Import e DirectQuery, credenciais e o gateway on-premises, a seleção enxuta de tabelas e, principalmente, como preservar o query folding para o banco fazer o trabalho pesado.

O conector de SQL Server gera Sql.Database por baixo#

Quando você usa o conector nativo, o Power Query não faz mágica. Ele escreve uma linha de código na linguagem M com a função Sql.Database. Vale conhecer essa função, porque entender o que a interface gera ajuda a resolver o que a interface esconde.

A forma mais comum recebe dois argumentos, o servidor e o banco de dados:

let
    Fonte = Sql.Database("SERVIDOR\INSTANCIA", "Vendas")
in
    Fonte

Esse Sql.Database com dois argumentos devolve a lista de tabelas e views do banco, para você navegar e escolher. Existe também a variação com um único argumento, Sql.Databases("SERVIDOR"), que lista todos os bancos do servidor. Na prática, você quase sempre quer apontar direto para o banco correto.

O Sql.Database também aceita um terceiro parâmetro opcional. É ali que você pode passar uma consulta nativa, quando faz sentido:

let
    Fonte = Sql.Database(
        "SERVIDOR\INSTANCIA",
        "Vendas",
        [Query = "SELECT * FROM dbo.FatoVendas WHERE Ano >= 2024"]
    )
in
    Fonte

Use esse Query com parcimônia. Escrever SQL na mão desliga parte da otimização automática do Power Query. Na maioria dos casos, deixe o Power Query gerar o SQL para você.

Import copia os dados, DirectQuery consulta ao vivo#

Logo depois de digitar o servidor e o banco, o Power BI faz uma pergunta que define a arquitetura inteira do projeto: Import ou DirectQuery? Muita gente clica em Import no automático e segue em frente. Vale parar dez segundos aqui, porque essa escolha é difícil de desfazer depois.

No modo Import, o Power BI executa as consultas uma vez, copia o resultado para dentro do arquivo e comprime tudo no motor VertiPaq. A partir daí, o relatório roda sobre essa cópia em memória. É rápido para o usuário e flexível para modelar. Em troca, o dado tem a idade da última atualização.

No modo DirectQuery, o Power BI não copia nada. Cada visual que o usuário abre dispara uma consulta ao vivo no SQL Server. O dado está sempre fresco, mas o desempenho depende do banco, e várias funcionalidades de DAX e de modelagem ficam limitadas.

A tabela abaixo resume a decisão do jeito que costumamos apresentar para o cliente:

Critério	Import	DirectQuery
Onde o dado fica	Copiado para o modelo (VertiPaq)	Permanece no SQL Server
Atualidade do dado	Da última atualização	Em tempo real
Desempenho dos visuais	Muito rápido (memória)	Depende do banco e da rede
Volume suportado	Limitado pela memória e licença	Adequado a bases muito grandes
Recursos de DAX	Completos	Restritos
Carga sobre o SQL Server	Só nas atualizações	A cada interação do usuário

Na prática, comece por Import. É a escolha certa para a grande maioria dos relatórios corporativos. Use DirectQuery quando houver exigência real de dado ao vivo, quando o volume não couber na memória, ou quando uma política proíba copiar o dado para fora do banco. O modelo composto ainda permite misturar as abordagens, mas isso já é um tema de arquitetura que tratamos em engenharia de dados.

Como fazer o Power Query conectar em um SQL Server, passo a passo#

Com a teoria no lugar, aqui está o caminho completo no Power BI Desktop:

1. Na guia Página Inicial, clique em Obter Dados e escolha SQL Server (ele também aparece direto no botão de fontes mais comuns).
2. Preencha o campo Servidor. Use o nome real, por exemplo SRVBI01 ou SRVBI01\PRODUCAO quando houver instância nomeada. Evite apontar para um IP fixo se o ambiente tiver DNS, porque isso complica a manutenção depois.
3. Preencha o campo Banco de dados (opcional, mas recomendado). Apontar direto para o banco correto deixa a navegação mais limpa e o código M mais explícito.
4. Escolha o modo de conectividade: Importar ou DirectQuery. Reveja a seção anterior antes de decidir.
5. Informe as credenciais na janela que aparece. Falaremos delas em detalhe no próximo tópico.
6. No Navegador, marque apenas as tabelas e views que você realmente vai usar. Resista à tentação de marcar tudo.
7. Clique em Transformar Dados para abrir o Editor do Power Query, em vez de clicar direto em Carregar. Você quase sempre vai querer filtrar linhas e remover colunas antes de carregar.
8. Aplique suas transformações, confira o desempenho e clique em Fechar e Aplicar.

O detalhe do passo 7 faz diferença. Clicar em Carregar de saída traz a tabela como está. Clicar em Transformar Dados abre o Editor, onde você pode enxugar o dado na origem e garantir o folding, que é o assunto que mais impacta a performance no fim das contas.

Credenciais e o gateway on-premises decidem se a atualização funciona#

Conectar no Desktop, na sua máquina, é a parte fácil. O momento da verdade é quando o relatório sobe para o Power BI Service e precisa se atualizar sozinho, sem você por perto. É aí que credenciais e gateway entram em cena.

Na janela de autenticação, o conector de SQL Server oferece basicamente duas rotas:

Tipo de autenticação	Quando usar	Observação
Windows	Ambiente com Active Directory, login integrado	Usa a conta do domínio; comum em SQL Server local
Banco de Dados (SQL)	Login e senha criados no próprio SQL Server	Peça uma conta de serviço com permissão de leitura

A recomendação de consultor é simples: para atualização agendada, use uma conta de serviço dedicada, não a sua conta pessoal. Se o relatório depender do seu usuário e você trocar de senha ou sair da empresa, a atualização quebra. Uma conta de serviço com permissão de leitura nas tabelas necessárias, e só nelas, é o padrão saudável.

Agora o ponto que mais gera chamado de suporte. Se o SQL Server é on-premises, ou seja, roda na infraestrutura da empresa e não numa nuvem pública acessível, o Power BI Service não enxerga esse banco sozinho. Para que a atualização agendada funcione, é obrigatório instalar e configurar o On-premises data gateway. O gateway é um agente que roda dentro da rede da empresa e faz a ponte segura entre o serviço na nuvem e o banco local.

O fluxo é este:

1. Instale o gateway num servidor que fique sempre ligado e que enxergue o SQL Server (não na máquina do analista).
2. Registre o gateway com a conta corporativa que administra o Power BI.
3. No Power BI Service, dentro das configurações do conjunto de dados, mapeie a fonte de dados do gateway informando servidor, banco e credenciais.
4. Configure a atualização agendada e faça um teste manual antes de confiar no agendamento.

Se o SQL Server estiver hospedado numa nuvem acessível pela internet, como uma VM ou um Azure SQL, muitas vezes você dispensa o gateway. Mas para o clássico SQL Server dentro do datacenter da empresa, considere o gateway parte obrigatória do projeto. A gente detalha esse tipo de configuração no conteúdo de sustentação de BI, porque manter atualização de pé é tão importante quanto construir o relatório.

Selecione só as tabelas necessárias, não o banco inteiro#

Existe um erro que aparece em quase todo projeto herdado: a pessoa marcou trinta tabelas no navegador porque não sabia quais precisaria, e o modelo carregou tudo. Meses depois, ninguém sabe o que é usado e o que é lixo, a atualização demora e o arquivo virou um monstro.

Traga só o que o relatório usa. Isso vale em duas dimensões:

• Menos tabelas. Marque no navegador apenas as tabelas e views que entram no modelo. Se descobrir depois que falta uma, adicionar é trivial. Remover uma tabela que virou dependência de dez medidas, não.
• Menos colunas e menos linhas. Dentro do Editor do Power Query, remova as colunas que não serão usadas e filtre as linhas cedo. Uma coluna de texto livre e larga que ninguém usa custa memória e tempo de atualização à toa.

Sempre que possível, filtre por data logo na origem. Um relatório operacional raramente precisa de dez anos de histórico completo. Trazer só os últimos vinte e quatro meses, por exemplo, reduz volume e acelera tudo:

let
    Fonte = Sql.Database("SRVBI01\PRODUCAO", "Vendas"),
    FatoVendas = Fonte{[Schema = "dbo", Item = "FatoVendas"]}[Data],
    Filtrado = Table.SelectRows(
        FatoVendas,
        each [DataVenda] >= #date(2024, 1, 1)
    ),
    ColunasUteis = Table.SelectColumns(
        Filtrado,
        {"DataVenda", "ProdutoID", "ClienteID", "Quantidade", "ValorLiquido"}
    )
in
    ColunasUteis

O bônus dessa disciplina não é só desempenho. Um modelo enxuto é mais fácil de entender, documentar e passar adiante, e esse cuidado no Power Query se conecta direto às boas práticas de modelagem DAX.

Preserve o query folding para o SQL Server fazer o trabalho pesado#

Este é o tópico que separa um relatório que escala de um que trava. Query folding é o mecanismo pelo qual o Power Query traduz suas transformações de volta para SQL e manda o SQL Server executá-las. Em vez de o Power Query puxar um milhão de linhas e filtrar na sua máquina, ele empurra o filtro para o banco, que devolve só o que interessa. O SQL Server é muito bom nisso, e o conector de SQL Server suporta folding muito bem.

Quando o folding funciona, uma transformação que você fez no Editor vira um WHERE, um GROUP BY ou um JOIN executado pelo banco. Quando ele quebra, o Power Query passa a trazer o dado bruto e processar localmente, o que fica lento e pesado.

Você verifica o folding clicando com o botão direito em uma etapa, na opção Exibir Consulta Nativa (View Native Query). Se ela estiver disponível e mostrar o SQL, a etapa está foldando. Se estiver acinzentada, o folding parou naquele ponto.

A tabela abaixo mostra o comportamento típico das operações mais comuns com o conector de SQL Server:

Operação	Comportamento com folding
Filtrar linhas	Costuma foldar (vira WHERE)
Remover ou selecionar colunas	Costuma foldar (vira SELECT)
Agrupar por / agregar	Costuma foldar (vira GROUP BY)
Renomear colunas	Costuma foldar
Mesclar consultas na mesma fonte	Costuma foldar (vira JOIN)
Adicionar coluna com lógica complexa em M	Tende a quebrar o folding
Usar Table.Buffer	Quebra o folding a partir dali
Passar um SQL nativo manual e transformar depois	O folding pode parar após a consulta

A regra prática que passo para os times é direta: coloque as transformações que foldam no começo da consulta e deixe qualquer etapa que quebre o folding para o final. Assim o banco faz o máximo de trabalho antes de o Power Query assumir. Filtrar linhas e remover colunas primeiro, colunas customizadas complexas por último.

Um exemplo de ordem que preserva o folding pelo maior tempo possível:

let
    Fonte = Sql.Database("SRVBI01\PRODUCAO", "Vendas"),
    Tabela = Fonte{[Schema = "dbo", Item = "FatoVendas"]}[Data],
    // etapas que foldam primeiro
    Filtrado = Table.SelectRows(Tabela, each [DataVenda] >= #date(2024, 1, 1)),
    Colunas = Table.SelectColumns(Filtrado, {"DataVenda", "ClienteID", "ValorLiquido"}),
    Agrupado = Table.Group(
        Colunas,
        {"ClienteID"},
        {{"TotalLiquido", each List.Sum([ValorLiquido]), type number}}
    )
    // qualquer etapa "não foldável" deveria vir depois daqui
in
    Agrupado

Se você precisa mesmo de uma transformação que não folda, tudo bem. Só garanta que ela venha depois de já ter reduzido o volume com filtros e projeções que foldaram. O objetivo é o SQL Server entregar o menor conjunto possível de dados para o Power Query terminar o serviço.

Perguntas frequentes#

Preciso instalar algum driver para o conector de SQL Server funcionar? No Power BI Desktop, o conector de SQL Server já vem pronto, não é preciso instalar driver adicional para o cenário padrão. A configuração que costuma faltar é do lado do servidor e da rede: liberar a porta, permitir a instância e garantir que a conta de serviço tenha permissão de leitura nas tabelas.

Consigo mudar de Import para DirectQuery depois que o relatório já está pronto? Migrar de Import para DirectQuery não é uma troca de botão trivial, porque muda regras de modelagem e de DAX. O caminho inverso, de DirectQuery para Import, é permitido no Desktop e mais simples. Por isso a recomendação é decidir bem no começo. Na dúvida, comece por Import.

Quando o gateway on-premises é obrigatório? Sempre que o SQL Server rodar dentro da rede da empresa, sem exposição direta à internet, e você quiser atualização agendada no Power BI Service. Sem o gateway, o Desktop atualiza na sua máquina, mas o serviço na nuvem não consegue alcançar o banco sozinho. Para bancos hospedados em nuvem acessível, o gateway costuma ser dispensável.

Como sei se minhas transformações estão preservando o query folding? Clique com o botão direito na etapa e escolha Exibir Consulta Nativa. Se a opção mostrar o SQL gerado, a etapa está foldando. Se estiver desabilitada, o folding parou ali. Reorganize as etapas para que as que foldam venham antes das que quebram o folding.

Devo escrever a consulta SQL na mão ou deixar o Power Query gerar? Na maioria dos casos, deixe o Power Query gerar o SQL. Ele fold suas etapas e mantém a manutenção mais visual. Escreva SQL nativo apenas quando precisar de algo que o Power Query não expressa bem, ciente de que o folding das etapas seguintes pode parar após a consulta nativa.

Uma conta pessoal serve para a atualização agendada? Serve para testar, mas não é recomendável em produção. Use uma conta de serviço dedicada com permissão de leitura restrita às tabelas necessárias. Assim a atualização não quebra quando alguém troca de senha ou sai da empresa, e a governança de acesso fica mais clara.

Conclusão#

Fazer o Power Query conectar em um SQL Server é rápido. Fazer essa conexão sobreviver em produção é o que separa um protótipo de uma solução. Escolha o conector nativo, decida Import ou DirectQuery com consciência, use uma conta de serviço e o gateway on-premises quando o banco for local, traga só as tabelas e colunas necessárias e mantenha o folding vivo para o SQL Server carregar o peso. Cada uma dessas decisões parece pequena isolada, mas juntas definem se o relatório vai escalar ou virar chamado recorrente.

Se você está estruturando essa camada de dados agora ou herdou um modelo que trava na atualização, fale com a gente. A Fynx já entregou mais de duas mil soluções Microsoft e pode ajudar seu time a conectar, modelar e sustentar tudo isso com segurança.