Resposta direta: no Microsoft Fabric, o Lakehouse trabalha melhor com Apache Spark e dados variados (estruturados ou não), e o Warehouse trabalha melhor com T SQL e transações entre várias tabelas. Os dois guardam dados no mesmo formato Delta, no OneLake. Muitos projetos usam os dois, cada um na camada em que funciona melhor.
A dúvida Fabric Lakehouse vs Warehouse aparece logo nas primeiras semanas de implementação, quando o time precisa decidir onde guardar e tratar os dados. A boa notícia: a escolha é menos definitiva do que parece, porque os dois compartilham o mesmo armazenamento. Este guia mostra a diferença, os critérios oficiais e a arquitetura que mais usamos.
Qual a diferença entre Lakehouse e Warehouse no Fabric?
O Lakehouse é um data lake com capacidade de consulta; o Warehouse é um data warehouse relacional completo em SQL. Os dois armazenam tabelas Delta no OneLake e usam o mesmo motor SQL para leitura, segundo o guia oficial de decisão entre Lakehouse e Warehouse do Microsoft Learn.
Em termos simples:
- Lakehouse: o time escreve com Spark (Python, Scala, Spark SQL ou R). Aceita arquivos de qualquer formato e tabelas. Para SQL, oferece um SQL analytics endpoint somente leitura.
- Warehouse: o time escreve com T SQL (INSERT, UPDATE, MERGE, procedures). Trabalha com dados estruturados e suporta transações entre várias tabelas.
Como Lakehouse e Warehouse se comparam?
| Critério | Lakehouse | Warehouse |
|---|---|---|
| Linguagem principal de escrita | Spark (Python, Scala, Spark SQL, R) | T SQL |
| Escrita via SQL | Não; o SQL analytics endpoint é só leitura (views e funções) | Sim, DML e DDL completos |
| Formato | Delta no OneLake, mais arquivos em qualquer formato | Delta no OneLake |
| Transações entre tabelas | Não (transações ACID por tabela, via Delta) | Sim, ACID entre várias tabelas |
| Tipos de dado | Estruturados, semiestruturados e não estruturados | Estruturados |
| Carga de dados | Spark, pipelines, dataflows, atalhos | COPY INTO, INSERT, CTAS, pipelines, dataflows |
| Perfil do time | Engenheiros de dados e cientistas de dados | Desenvolvedores SQL e engenheiros de BI |
| Consumo pelo Power BI | Direct Lake ou SQL analytics endpoint | Direct Lake ou endpoint do Warehouse |
Fonte: Microsoft Learn, atualizado em setembro de 2026.
Como decidir entre Lakehouse e Warehouse?
A Microsoft propõe três perguntas, e a beAnalytic acrescenta uma quarta.
- Como o time quer desenvolver? Spark aponta para Lakehouse; T SQL aponta para Warehouse.
- Precisa de transações entre várias tabelas? Sim aponta para Warehouse.
- Que tipo de dado chega? Dados não estruturados, variados ou incertos apontam para Lakehouse; só estruturados podem ir para Warehouse.
- Quem vai manter isso daqui a dois anos? (critério beAnalytic) Escolha a tecnologia que o time disponível no mercado e dentro da empresa consegue sustentar.
Frase de decisão por perfil: time forte em Python, dados variados e muita transformação: Lakehouse. Time forte em SQL, dados de ERP já estruturados e regras de negócio em procedures: Warehouse. Time misto: os dois, cada um em sua camada.
Qual arquitetura usamos com mais frequência?
Lakehouse nas camadas bronze e prata, e Warehouse ou Lakehouse na camada ouro, conforme o perfil de quem consome. É o padrão 2 descrito no guia oficial de arquitetura medalhão no Fabric.
Fontes (ERP, CRM, arquivos)
│
▼
[Bronze] Lakehouse → dado bruto, como chegou (Spark, pipelines, atalhos)
│
▼
[Prata] Lakehouse → dado limpo e padronizado (notebooks Spark)
│
▼
[Ouro] Warehouse → fatos e dimensões em T SQL (time de BI)
│
▼
Power BI (Direct Lake)
Por quê: a entrada de dados variados e a limpeza pesada rendem mais com Spark. A camada final, que o time de BI mantém e onde ficam as regras de negócio, rende mais com T SQL e transações. Quando o time é todo de engenharia em Python, usamos Lakehouse também no ouro. Detalhamos a organização das camadas no guia de arquitetura medalhão no Fabric na prática.
Quais armadilhas evitar?
- Atraso do SQL analytics endpoint. Alterações nas tabelas do Lakehouse podem levar de segundos a minutos para aparecer no endpoint SQL. Relatórios e cargas que leem logo depois de uma escrita podem pegar dado antigo.
- Tentar escrever pelo endpoint SQL. O endpoint do Lakehouse é só leitura. Quem espera UPDATE ali descobre tarde que precisa de Spark ou de um Warehouse.
- Permissões em dois lugares. Lakehouse e Warehouse têm modelos de permissão próprios. Defina por camada quem acessa o quê.
- Duplicação de dados entre camadas. Copiar a mesma tabela para Lakehouse e Warehouse sem necessidade dobra armazenamento e manutenção. Consultas entre bancos no mesmo workspace leem sem copiar.
Para a diferença conceitual entre data lake, data warehouse e lakehouse fora do Fabric, veja o guia data lake ou data warehouse.
Caso ilustrativo: indústria farmacêutica com time misto
Cenário ilustrativo, montado a partir de situações comuns em projetos de dados. A empresa e os números são hipotéticos; as funcionalidades citadas são as oficiais do Microsoft Fabric.
Contexto. Uma indústria farmacêutica tinha 2 engenheiros de dados fortes em Python e 5 analistas de BI fortes em SQL. As fontes eram o ERP, um sistema de qualidade com laudos em PDF e planilhas de laboratório. A primeira versão do projeto colocou tudo em Lakehouse.
Problema. Os analistas de BI precisavam corrigir regras de negócio com UPDATE e procedures, mas o SQL analytics endpoint é só leitura. Cada ajuste virava pedido para os 2 engenheiros, que acumularam uma fila de 3 semanas.
Decisão. Bronze e prata continuaram em Lakehouse, porque laudos em PDF e planilhas variadas pediam Spark. A camada ouro foi movida para um Warehouse, mantido pelos analistas em T SQL. O Power BI passou a ler o ouro em Direct Lake.
| Indicador | Antes | Depois |
|---|---|---|
| Tempo para ajustar uma regra de negócio | Fila de até 3 semanas | 1 a 2 dias, pelo próprio time de BI |
| Quem mantém a camada ouro | 2 engenheiros | 5 analistas de BI |
| Cópias duplicadas de tabelas | 11 | 0 (consultas entre bancos) |
O que esse cenário ensina: a melhor escolha seguiu o perfil de quem mantém cada camada. A tecnologia de armazenamento é a mesma; o que muda é quem consegue trabalhar nela.
Resumo para encaminhar à diretoria
- Problema: precisamos definir onde guardar e tratar os dados no Fabric.
- Opções: Lakehouse (Spark, dados variados), Warehouse (T SQL, transações) ou os dois por camada.
- Custo ou risco: escolher contra o perfil do time cria gargalo e dependência de poucas pessoas.
- Recomendação: Lakehouse em bronze e prata; ouro em Warehouse quando o time de BI é forte em SQL.
- Próximo passo: revisão de arquitetura Fabric com o perfil real do time e das fontes.
Perguntas frequentes sobre Lakehouse e Warehouse no Fabric
Posso usar Lakehouse e Warehouse juntos?
Sim. É o padrão mais comum em projetos maiores. Os dois guardam dados no OneLake e permitem consultas entre bancos no mesmo workspace sem copiar dados.
O Power BI lê dos dois do mesmo jeito?
Sim. Os dois suportam o modo Direct Lake e acesso por endpoint SQL. A diferença está em como os dados são escritos, não em como são lidos.
Qual é mais rápido?
Depende da carga. Para transformações pesadas e dados variados, o Spark do Lakehouse costuma render mais. Para consultas e transformações em SQL sobre dados estruturados, o Warehouse é otimizado para isso.
Qual custa menos?
Os dois consomem CUs da mesma capacidade Fabric e o mesmo armazenamento no OneLake. O custo depende mais do volume processado e da eficiência das cargas do que do item escolhido.
Dá para mudar depois?
Sim. Como os dois usam Delta no OneLake, mover uma camada de um para o outro exige reescrever as cargas, mas não converter formato de dados.
Está desenhando o seu ambiente Fabric? A beAnalytic é consultoria de dados e faz revisões de arquitetura Fabric antes que a escolha vire retrabalho. Peça uma revisão de arquitetura com a nossa consultoria de engenharia de dados ou escreva para [email protected].
Daniel Luz
CEO da beAnalytic. Na liderança da empresa há mais de 6 anos, minha missão é transformar a forma como as organizações enxergam e utilizam dados para tomar decisões estratégicas. Ajudo empresas a destravar insights valiosos, impulsionar eficiência operacional e gerar impacto financeiro real, com uma equipe especializada em Business Intelligence, Engenharia de Dados e Machine Learning.
- Daniel Luz
- Daniel Luz
- Daniel Luz
- Daniel Luz
