Warehouse no Microsoft Fabric: quando escolher

A decisão que trava a primeira semana de qualquer projeto no Fabric#

Quando um time abre o Microsoft Fabric pela primeira vez para começar um projeto de dados sério, a primeira decisão importante não é sobre pipeline nem sobre modelagem. É esta: criar um Warehouse ou um Lakehouse? Os dois aparecem lado a lado no menu de criação de itens, os dois guardam dados no OneLake, os dois expõem um endpoint SQL, e a documentação da Microsoft descreve ambos com palavras parecidas o suficiente para gerar dúvida. O resultado é previsível: alguém escolhe no chute, o projeto avança, e três meses depois o time descobre que escolheu a ferramenta errada para o jeito que trabalha.

O Warehouse no Microsoft Fabric é um data warehouse relacional completo, com T-SQL, transações e escrita nativa via SQL. O Lakehouse é orientado a data lake, com escrita por Spark e leitura relacional através de um endpoint SQL somente leitura. Essa frase resume a diferença, mas ela não resolve a decisão sozinha. Neste artigo eu vou destrinchar o que cada um faz de verdade, onde eles divergem, quando escolher cada um e, principalmente, como os dois convivem sobre o mesmo OneLake sem virar uma bagunça de cópias. Com exemplos de T-SQL, para você sair daqui sabendo o que digitar.

O que é o Warehouse no Microsoft Fabric#

O Warehouse é o data warehouse nativo do Fabric. Na prática, ele se comporta como um banco relacional que você já conhece: você cria tabelas com CREATE TABLE, insere linhas com INSERT, atualiza com UPDATE, deleta com DELETE e consulta com SELECT. Tudo em T-SQL, a mesma linguagem do SQL Server e do Azure SQL. Para um time que vem de SQL Server, a curva de aprendizado é curta, porque a superfície da linguagem é familiar.

A diferença estrutural em relação ao SQL Server tradicional está embaixo do capô. O Warehouse do Fabric não guarda os dados em arquivos proprietários de banco. Ele grava tudo em formato Delta Lake, dentro do OneLake, o mesmo armazenamento único que todo o Fabric compartilha. Ou seja, você escreve com sintaxe de banco relacional, mas o dado físico fica em Parquet mais log de transação Delta, aberto e legível por qualquer outro motor que fale Delta.

O ponto que mais importa para a decisão: o Warehouse tem suporte completo a transações multi-tabela. Você consegue abrir uma transação, alterar várias tabelas e dar commit ou rollback atômico. Isso muda o jogo para cargas onde consistência entre tabelas é obrigatória.

-- Warehouse: transação multi-tabela com commit atômico
BEGIN TRANSACTION;

UPDATE dim_cliente
SET status = 'inativo'
WHERE ultima_compra < '2024-01-01';

INSERT INTO log_auditoria (tabela, acao, data_evento)
VALUES ('dim_cliente', 'inativacao_lote', GETDATE());

COMMIT TRANSACTION;

Se algo falhar no meio, um ROLLBACK desfaz tudo e você não fica com metade da carga aplicada. Esse é o tipo de garantia que um time de dados relacional espera e que o Lakehouse não entrega da mesma forma pela via SQL.

O que é o Lakehouse e por que ele é diferente#

O Lakehouse é a peça orientada a lake do Fabric. Ele foi desenhado para quem trabalha com arquivos, notebooks e Spark. Você ingere arquivos (CSV, Parquet, JSON), organiza em uma área de tabelas Delta e transforma os dados com PySpark, Spark SQL ou Dataflows. A escrita de dados no Lakehouse acontece por Spark ou por ferramentas de ingestão, não por comando INSERT de SQL.

O Lakehouse também expõe um endpoint SQL, e é aí que mora a confusão. Esse endpoint permite rodar SELECT sobre as tabelas do Lakehouse com T-SQL, conectar o Power BI, cruzar tabelas e criar views. Mas ele é somente leitura. Você não faz INSERT, UPDATE ou DELETE por esse endpoint. Ele existe para consulta e consumo, não para gravação transacional.

-- Lakehouse via endpoint SQL: leitura funciona
SELECT categoria, SUM(valor) AS total
FROM vendas
GROUP BY categoria;

-- Lakehouse via endpoint SQL: escrita NÃO funciona por aqui
-- INSERT INTO vendas (...) VALUES (...);  -> não suportado
-- A escrita no Lakehouse é feita por Spark / notebooks

Para gravar no Lakehouse você usaria um notebook Spark, mais ou menos assim:

# Lakehouse: escrita via Spark, não via T-SQL
df = spark.read.format("csv").option("header", "true").load("Files/vendas_raw.csv")
df.write.mode("append").format("delta").saveAsTable("vendas")

Essa é a divisão de trabalho de fundo: Lakehouse escreve com código (Spark), Warehouse escreve com SQL. Ambos leem com SQL. Se você entender só isso, já toma 80% das decisões corretamente.

Warehouse x Lakehouse: a tabela que resolve a maioria das dúvidas#

A comparação lado a lado deixa a diferença concreta. Guarde esta tabela, ela vale mais do que qualquer explicação longa.

Característica	Warehouse	Lakehouse
Perfil principal	Data warehouse relacional	Data lake com camada relacional
Escrita de dados	T-SQL nativo (INSERT/UPDATE/DELETE/MERGE)	Spark, notebooks, Dataflows
Leitura via SQL	Sim, completa	Sim, via endpoint SQL somente leitura
Transações multi-tabela	Sim, com commit/rollback atômico	Não pela via T-SQL
Linguagem principal	T-SQL	PySpark / Spark SQL
Armazenamento	Delta no OneLake	Delta no OneLake
Melhor para quem vem de	SQL Server, Azure SQL, mundo relacional	Databricks, Spark, engenharia com código
Ingestão de arquivos brutos	Limitada, foco em dado já estruturado	Nativa, é o ponto forte

Repare na penúltima linha: os dois guardam dado em Delta no OneLake. Isso não é detalhe, é a base de tudo que vem a seguir sobre convivência. A escolha entre os dois não decide onde o dado mora. Decide como você escreve e transforma.

Quando escolher o Warehouse#

Escolha o Warehouse quando o perfil do time e da carga for relacional. Alguns sinais claros:

• O time é de T-SQL. Analistas e engenheiros que dominam SQL Server produzem muito mais rápido em um ambiente que fala a mesma língua. Forçar esse time a aprender Spark só para escrever dado é desperdício de tempo.
• Você precisa de escrita transacional via SQL. Cargas que fazem MERGE de dimensões, atualização de fatos, correção pontual de registros ou operações que exigem consistência entre tabelas pedem o Warehouse.
• A modelagem é star schema clássica. Fatos, dimensões, chaves substitutas, tudo isso é o território natural de um data warehouse relacional.
• Stored procedures e views fazem parte do design. O Warehouse suporta procedures em T-SQL, o que permite encapsular lógica de transformação dentro do próprio banco.

Um exemplo típico de carga incremental de dimensão no Warehouse, usando MERGE, mostra por que esse ambiente é confortável para quem pensa em SQL:

-- Warehouse: carga incremental de dimensão com MERGE
MERGE INTO dim_produto AS destino
USING stg_produto AS origem
    ON destino.produto_id = origem.produto_id
WHEN MATCHED AND destino.preco <> origem.preco THEN
    UPDATE SET destino.preco = origem.preco,
               destino.atualizado_em = GETDATE()
WHEN NOT MATCHED THEN
    INSERT (produto_id, nome, preco, atualizado_em)
    VALUES (origem.produto_id, origem.nome, origem.preco, GETDATE());

Esse tipo de operação é o pão com manteiga de quem construiu warehouse a vida inteira. Se descreve o seu time, o Warehouse é a escolha honesta.

Quando escolher o Lakehouse#

Escolha o Lakehouse quando o trabalho começa com arquivos e código. Sinais claros:

• Você ingere volumes grandes de arquivos brutos. Logs, exportações, dados semiestruturados, JSON aninhado. O Lakehouse foi feito para receber isso na camada de arquivos e transformar com Spark.
• O time já trabalha com Spark ou vem de Databricks. Notebooks em PySpark, transformações distribuídas, machine learning sobre os dados. Esse ecossistema é o habitat do Lakehouse.
• A transformação é pesada e distribuída. Quando o processamento se beneficia de paralelismo Spark, o Lakehouse entrega melhor do que forçar tudo em T-SQL.
• A arquitetura é medalhão (bronze, prata, ouro). Camadas de refinamento progressivo com notebooks entre elas casam com o modelo do Lakehouse.

Se o seu projeto envolve engenharia de dados com código e transformação em escala, vale conhecer como a gente estrutura isso em engenharia de dados. E se você ainda está decidindo a arquitetura macro antes de escolher a ferramenta, o artigo sobre o que é o Microsoft Fabric e se vale a pena em 2026 dá o pano de fundo.

Como Warehouse e Lakehouse convivem sobre o OneLake#

Aqui está a parte que muda a conversa: você não precisa escolher só um. Como Warehouse e Lakehouse guardam dados em Delta no mesmo OneLake, os dois se enxergam. Um Warehouse pode consultar tabelas de um Lakehouse e vice-versa, sem copiar o dado fisicamente. Isso é feito com cross-database query e com atalhos (shortcuts).

O padrão que mais funciona na prática divide o trabalho por afinidade:

Camada	Ferramenta	Papel
Ingestão e refinamento pesado	Lakehouse	Recebe arquivos brutos, transforma com Spark, entrega tabelas prata
Modelagem e serving relacional	Warehouse	Consome as tabelas do Lakehouse, monta star schema, serve o BI com T-SQL
Consumo	Power BI	Lê do Warehouse (ou direto via Direct Lake)

Nesse desenho, o Spark faz o trabalho sujo de ingestão e limpeza no Lakehouse, e o Warehouse assume a modelagem final e o serving, onde o T-SQL brilha. O melhor: não há cópia de dados entre as camadas, porque tudo aponta para o mesmo OneLake.

A consulta cruzada é direta. De dentro do Warehouse, você referencia uma tabela do Lakehouse pelo nome de três partes:

-- Warehouse consultando uma tabela do Lakehouse (cross-database)
-- Formato: [Lakehouse].[schema].[tabela]
SELECT c.regiao, SUM(v.valor) AS receita
FROM MeuLakehouse.dbo.vendas AS v
JOIN dim_cliente AS c
    ON v.cliente_id = c.cliente_id
GROUP BY c.regiao;

Nesse exemplo, vendas vive no Lakehouse (foi carregada por Spark) e dim_cliente vive no Warehouse (gerenciada por T-SQL). A junção acontece sem mover nada. Essa é a promessa central do OneLake se materializando: um dado, vários motores.

O erro comum: escolher pela moda, não pelo time#

O erro que eu mais vejo é o time escolher Lakehouse porque "lake é moderno" e Warehouse porque "warehouse é o que a gente sempre usou", sem olhar para quem vai operar aquilo no dia a dia. A ferramenta certa é a que o seu time consegue manter com qualidade daqui a um ano, não a que rendeu o slide mais bonito na reunião de arquitetura.

Se o seu time inteiro é de SQL e você escolheu Lakehouse, cada transformação vira um pequeno projeto de aprendizado de Spark e a velocidade despenca. Se o time é de engenharia com código e você impôs um Warehouse puro, você desperdiça o processamento distribuído. A honestidade técnica aqui é simples: case a ferramenta com a competência instalada e use a convivência sobre o OneLake para cobrir as pontas.

Para projetos de BI que terminam no Power BI, a escolha entre Warehouse e Lakehouse também afeta o modo de conexão e a performance dos relatórios. Se o consumo final é o que mais importa para você, vale alinhar isso com quem cuida do Power BI do começo, para não descobrir gargalo de refresh só na produção. E quando a decisão envolve dimensionar capacidade e custo, dá para desenhar o ambiente com apoio de quem já fez isso em analytics avançado.

Perguntas frequentes#

O Warehouse no Microsoft Fabric substitui o SQL Server?

Para cargas analíticas, ele cumpre o papel de data warehouse com T-SQL sobre o OneLake, então em muitos cenários de BI e analytics sim, ele substitui um SQL Server usado como warehouse. Para cargas transacionais de aplicação (OLTP, muitos writes pequenos e concorrentes), ele não é o alvo. O Warehouse do Fabric é analítico, não é um banco de sistema operacional.

Posso escrever no Lakehouse usando T-SQL?

Não pelo endpoint SQL, que é somente leitura. A escrita de dados no Lakehouse é feita por Spark, notebooks ou ferramentas de ingestão como Dataflows e pipelines. Você usa T-SQL no Lakehouse apenas para consultar. Se você precisa escrever via SQL, o item certo é o Warehouse.

Os dois guardam os dados no mesmo lugar?

Sim. Tanto o Warehouse quanto o Lakehouse gravam em formato Delta dentro do OneLake, o armazenamento único do Fabric. Por isso um consegue consultar as tabelas do outro sem copiar dado, usando cross-database query ou shortcuts. A escolha entre os dois define como você escreve e transforma, não onde o dado mora.

Preciso escolher só um para o projeto todo?

Não, e na maioria dos projetos maduros você usa os dois. O padrão comum é o Lakehouse na ingestão e transformação pesada com Spark e o Warehouse na modelagem relacional e no serving do BI. Como ambos vivem sobre o OneLake, essa divisão não gera cópia de dados nem duplicação de esforço.

Qual dos dois conecta melhor no Power BI?

Os dois conectam bem, porque ambos expõem endpoint SQL e ambos suportam Direct Lake, o modo de conexão do Fabric que lê Delta direto sem importar. A decisão de qual usar como fonte do relatório depende de onde está a sua camada de serving modelada. Se o star schema final está no Warehouse, aponte o Power BI para ele.

Vale a pena migrar um data warehouse Azure SQL para o Warehouse do Fabric?

Depende do apetite por Fabric e da estratégia de plataforma. A migração é atraente quando você quer unificar armazenamento no OneLake e aproveitar a convivência com Lakehouse e Power BI na mesma capacidade. Não é uma migração trivial nem obrigatória, e faz mais sentido dentro de uma decisão maior de adotar o Fabric como plataforma de dados, não como troca isolada de banco.

Conclusão#

O Warehouse no Microsoft Fabric é o data warehouse T-SQL com escrita transacional, e o Lakehouse é a peça orientada a lake com escrita por Spark e leitura por SQL. A diferença não é sobre qual é melhor, é sobre o que o seu time faz bem. Escolha o Warehouse quando a competência é relacional e você precisa gravar via SQL. Escolha o Lakehouse quando o trabalho começa em arquivos e código. E lembre que os dois convivem sobre o OneLake, então na dúvida você combina os dois em vez de apostar tudo em um.

Se você está desenhando essa arquitetura agora e quer evitar o retrabalho de escolher errado, fale com a gente. A gente ajuda a montar o ambiente Fabric certo para o jeito que o seu time trabalha.