Lakehouse vs Warehouse no Microsoft Fabric: T-SQL ou PySpark?

Resumo rápido

A escolha entre Lakehouse e Warehouse no Fabric começa por uma pergunta: em que linguagem você vai trabalhar? PySpark (ou Spark SQL) aponta para o Lakehouse; T-SQL aponta para o Warehouse. Os dois guardam os dados em formato Delta no OneLake e compartilham o mesmo mecanismo de SQL, então a diferença está em como você desenvolve, não em onde os dados ficam.

O guia de decisão da Microsoft resume tudo em três perguntas:

Qual é a linguagem de desenvolvimento? Spark (Python, Scala, Spark SQL ou R) → Lakehouse. T-SQL → Warehouse.
Você precisa de transações envolvendo várias tabelas? Sim → Warehouse. Não → Lakehouse.
Que tipo de dado você analisa? Estruturado e não estruturado, ou você ainda não tem certeza → Lakehouse. Somente estruturado → Warehouse.

O resultado dessas três perguntas é um ponto de partida. O restante do artigo mostra como confirmar a escolha.

O que é cada um

Warehouse é um data warehouse relacional em escala corporativa, desenvolvido principalmente em T-SQL. Ele oferece transações ACID envolvendo várias tabelas, views, funções e stored procedures, e carrega dados por COPY INTO, pipelines, dataflows e consultas entre bancos. Pode ler e gravar tabelas Delta.

Lakehouse é uma arquitetura para armazenar e analisar dados estruturados e não estruturados no mesmo lugar. Usa Delta Lake (transações ACID, imposição de esquema e time travel), aceita atalhos (shortcuts) para dados externos sem copiá-los e permite trabalhar com Spark em notebooks.

SQL analytics endpoint é o detalhe que mais confunde. Todo Lakehouse ganha um endpoint T-SQL gerado automaticamente, mas ele é somente leitura: aceita consultas, views e funções com valor de tabela, porém não aceita INSERT, UPDATE ou DELETE. Para gravar em tabelas do Lakehouse, você usa Spark, pipelines ou dataflows.

T-SQL vs PySpark na prática

T-SQL é declarativo e orientado a tabelas: você descreve o resultado e o mecanismo de SQL decide como chegar lá. PySpark é código Python sobre DataFrames, rodando em notebooks, o que dá mais flexibilidade para ler arquivos de vários formatos, aplicar lógica programática e tratar dados que não cabem bem em linhas e colunas.

O mesmo objetivo, agrupar vendas por cliente, fica assim nos dois lados.

T-SQL no Warehouse:

CREATE TABLE dbo.vendas_por_cliente AS
SELECT
    cliente_id,
    COUNT(*)        AS qtd_pedidos,
    SUM(valor)      AS valor_total
FROM dbo.pedidos
GROUP BY cliente_id;

PySpark no Lakehouse:

from pyspark.sql import functions as F

df = spark.read.table("pedidos")

vendas_por_cliente = (
    df.groupBy("cliente_id")
      .agg(
          F.count("*").alias("qtd_pedidos"),
          F.sum("valor").alias("valor_total"),
      )
)

vendas_por_cliente.write.format("delta").mode("overwrite").saveAsTable("vendas_por_cliente")

Para esse caso, o T-SQL é mais curto e direto. O PySpark compensa quando a etapa anterior é ler CSV, JSON ou Parquet de uma pasta, limpar tipos, tratar nulos e só depois gravar a tabela, tudo no mesmo notebook.

Também dá para usar SQL dentro do Lakehouse: o Spark SQL roda em notebooks, e o SQL analytics endpoint aceita T-SQL só para leitura. Ele é uma forma útil de deixar analistas consultarem as tabelas, mas não substitui o Warehouse quando a transformação precisa gravar dados em T-SQL.

Exemplo prático: do CSV ao relatório

Vamos ver isso na prática com um exemplo simples: chega um CSV de pedidos e você precisa entregar um relatório de vendas por cliente.

O desenho resume a ideia: o PySpark cuida de tudo que grava dados, e o T-SQL só entra no final, para consultar. Isso acontece porque o SQL analytics endpoint do Lakehouse é somente leitura.

A primeira etapa é a limpeza. A gente lê o CSV, remove pedidos duplicados, converte a data e descarta linhas sem valor. O resultado vira a tabela pedidos:

from pyspark.sql import functions as F

bruto = (
    spark.read
    .option("header", True)
    .option("inferSchema", True)
    .csv("Files/pedidos/pedidos.csv")
)

pedidos = (
    bruto.dropDuplicates(["pedido_id"])
         .withColumn("data_pedido", F.to_date("data_pedido"))
         .filter(F.col("valor").isNotNull())
)

pedidos.write.format("delta").mode("overwrite").saveAsTable("pedidos")

Depois vem a agregação, que é o mesmo código da seção anterior: ele lê pedidos e grava a tabela vendas_por_cliente.

Com a tabela pronta, qualquer pessoa consulta o resultado em T-SQL pelo endpoint do Lakehouse:

SELECT TOP 10 cliente_id, valor_total
FROM dbo.vendas_por_cliente
ORDER BY valor_total DESC;

Por fim, o semantic model do Power BI lê as tabelas gold e alimenta o relatório.

E o Warehouse nessa história? Se o seu time prefere modelar a camada gold em T-SQL, a agregação pode acontecer num Warehouse, que consegue consultar as tabelas do Lakehouse sem duplicar os dados. Aí o Lakehouse fica com a limpeza em PySpark e o Warehouse com a modelagem em T-SQL.

Comparativo lado a lado

Critério	Warehouse	Lakehouse (com SQL analytics endpoint)
Linguagem principal	T-SQL	Spark (PySpark, Spark SQL, Scala, R) em notebooks; T-SQL só para leitura no endpoint
Gravação via T-SQL (DML)	Sim, com suporte completo a transações	Não: o endpoint é somente leitura
Transações em várias tabelas	Sim	Não é o foco; o guia manda usar o Warehouse
Tipos de dado	Estruturados	Estruturados e não estruturados
Armazenamento	Delta no OneLake	Delta no OneLake
Carga de dados	`COPY INTO`, `INSERT`, `CREATE TABLE AS SELECT`, pipelines, dataflows	Spark, pipelines, dataflows, shortcuts
T-SQL disponível	Consulta, DML e DDL completos	Consulta completa, sem DML, DDL limitado (views e funções com valor de tabela)
Perfil típico	Desenvolvedores SQL ou citizen developers	Engenheiros de dados ou desenvolvedores SQL
Uso recomendado	Data warehouse corporativo ou departamental; análise estruturada em T-SQL	Arquitetura medalhão (bronze, silver, gold); exploração; zona de staging e arquivo

Fonte: Microsoft Learn, guia de decisão Warehouse e Lakehouse

Quando escolher cada um

Escolha o Warehouse quando:

o time trabalha em T-SQL e quer continuar com tabelas, views, procedures e funções;
os dados já são estruturados e o objetivo principal é análise e BI;
você precisa gravar e transformar dados com T-SQL (INSERT, UPDATE, DELETE) com suporte completo a transações;
uma regra de negócio exige transação envolvendo várias tabelas.

Escolha o Lakehouse quando:

o time trabalha com PySpark, Spark SQL ou notebooks;
os dados chegam como arquivos em formatos variados (CSV, JSON, Parquet) ou incluem dados não estruturados;
você quer organizar as camadas bronze, silver e gold da arquitetura medalhão;
precisa acessar dados externos sem copiá-los, usando shortcuts do OneLake;
você ainda não sabe como os dados vão evoluir: o guia da Microsoft indica Lakehouse quando há dúvida sobre o tipo de dado.

Uma regra prática: decida pelo time e pelo tipo de dado, não pela moda. Um time forte em SQL que força tudo para Spark perde produtividade, e o contrário também vale.

Segurança, custo e desempenho

Segurança

O acesso combina permissões do Fabric (função no workspace ou permissão no item) com permissões SQL granulares. A recomendação da Microsoft é o princípio do menor privilégio: quem só precisa ler pode ficar na função Viewer, com acesso concedido por T-SQL a objetos específicos.

No Warehouse e no SQL analytics endpoint, dá para proteger os dados com segurança em nível de objeto, de coluna e de linha, além de máscara dinâmica de dados (dynamic data masking), tudo por T-SQL e sem mudar as aplicações. O Warehouse também oferece logs de auditoria de usuário (via Microsoft Purview e PowerShell) e chaves de criptografia gerenciadas pelo cliente (CMK). Para o endpoint do Lakehouse, a Microsoft mantém uma página própria, OneLake security for SQL analytics endpoints.

Custo e capacidade

Os dois rodam na mesma capacidade Fabric, cujas unidades (CUs) são compartilhadas por todas as cargas. A diferença está em como cada lado consome:

Warehouse: o consumo é medido em vNodes (cada um com quatro vCores), alocados e liberados conforme a demanda. Leitura e gravação no Warehouse e leitura no SQL analytics endpoint do Lakehouse consomem capacidade, e as duas aparecem juntas como Warehouse no app de métricas, porque usam o mesmo motor SQL.
Spark (Lakehouse): cada CU equivale a dois vCores Spark. A cobrança começa quando um notebook, um job ou uma operação do Lakehouse começa a rodar, e o tempo ocioso do pool não é cobrado. A sessão expira por padrão em 20 minutos; para parar a cobrança antes, encerre a sessão. Existe ainda a opção de autoscale billing para Spark, com recursos serverless e um limite máximo de CUs.

Na prática, a pergunta de custo não é “qual item é mais barato”, e sim “como a minha carga usa a capacidade”. O app Fabric Capacity Metrics mostra isso para os dois lados.

Desempenho

Este artigo não compara velocidade entre Lakehouse e Warehouse: o resultado depende da carga, do volume de dados e de como as tabelas são escritas. Meça com uma amostra dos seus dados antes de decidir. Para o Warehouse, a Microsoft mantém um guia próprio, Performance guidelines in Fabric Data Warehouse.

Você não precisa escolher só um

Lakehouse e Warehouse convivem bem no mesmo projeto. Os dois usam Delta no OneLake, e o Warehouse consegue fazer consultas entre warehouses e lakehouses sem duplicar dados. A própria Microsoft cita como caso de uso do Lakehouse o pareamento com um Warehouse para análise corporativa.

Um desenho comum na arquitetura medalhão:

Bronze: Lakehouse recebe os dados brutos (arquivos, extrações, shortcuts).
Silver: notebooks PySpark no Lakehouse limpam, tipam e deduplicam.
Gold: modelo dimensional (fatos e dimensões) pronto para consumo. Pode ficar no próprio Lakehouse ou em um Warehouse, se o time preferir modelar e transformar em T-SQL.
Consumo: semantic model e relatórios no Power BI.

Não existe uma resposta única para o Gold. Se a equipe quer procedures em T-SQL e gravação por SQL, o Warehouse faz sentido. Se toda a cadeia já está em PySpark e o consumo é só leitura, manter o Gold no Lakehouse reduz a quantidade de peças.

Armadilhas comuns

Tentar gravar pelo SQL analytics endpoint. Ele é somente leitura. Se o plano é INSERT, UPDATE ou DELETE em T-SQL, o item certo é o Warehouse; no Lakehouse, a escrita vai por Spark, pipelines ou dataflows.
Tratar os dois como mundos separados. Ambos guardam Delta no OneLake e dá para consultar um a partir do outro, então a escolha não trava a arquitetura para sempre.
Confundir Spark SQL com T-SQL. São dialetos diferentes. Uma consulta que funciona em um notebook pode não rodar no endpoint ou no Warehouse sem ajustes.
Escolher pela ferramenta, não pelo time. Antes de decidir, pergunte quem vai manter o pipeline daqui a seis meses e em que linguagem essa pessoa é mais produtiva.

Perguntas frequentes

Dá para usar T-SQL no Lakehouse? Sim, para leitura. O SQL analytics endpoint aceita consultas, views e funções com valor de tabela. Para gravar, use Spark, pipelines ou dataflows.

Dá para usar PySpark com o Warehouse? O Warehouse é desenvolvido em T-SQL. Existe um conector Spark para acessar os dados dele, descrito na documentação listada nas fontes.

O SQL analytics endpoint consome capacidade? Sim. A leitura no endpoint conta como uso de computação do Warehouse e aparece junto com ele no app de métricas.

Escolher um deles me prende para sempre? Não. Os dois guardam Delta no OneLake e dá para consultar um a partir do outro. O que não migra sozinho é o código: uma transformação escrita em PySpark precisa ser reescrita para rodar em T-SQL, e o inverso também.

Conclusão

Escolha o Lakehouse se o seu trabalho é PySpark, arquivos e dados de vários tipos; escolha o Warehouse se é T-SQL, dados estruturados e gravação por SQL. Na dúvida sobre o tipo de dado, comece pelo Lakehouse, e lembre que os dois podem conviver no mesmo projeto.

Fontes

Vídeo sobre o tema

Prefere ver na prática? No vídeo Lakehouse x Warehouse no Fabric (Spark x T-SQL) — Direto pra DP-600 eu mostro as diferenças direto no Fabric.