Microsoft Fabric: o que é, como funciona e quando vale a pena em 2026

O problema que o Microsoft Fabric tenta resolver#

Toda empresa que cresce com dados chega no mesmo impasse: o time de engenharia trabalha em uma ferramenta, o de análise em outra, o BI em uma terceira, e entre elas existem cópias de dados, jobs de ETL frágeis e um custo de integração que ninguém projetou na planilha original. O Microsoft Fabric nasceu para atacar esse problema — não é um produto do zero, é a tentativa da Microsoft de unificar Synapse, Data Factory, Power BI e um lakehouse nativo numa única plataforma SaaS, com um só local de armazenamento e um só modelo de governança.

Lançado em disponibilidade geral em 2023 e amadurecido ao longo de 2024 e 2025, o Fabric chega em 2026 numa fase diferente: já não é novidade experimental, mas também ainda não é escolha óbvia para todo cliente. Este artigo explica como ele funciona por dentro, o que muda em relação ao Synapse, como o custo por capacidade funciona na prática e — o mais importante para quem decide orçamento — quando vale migrar agora e quando é mais sensato esperar.

Se você ainda está decidindo entre investir em BI tradicional ou dar o salto para uma arquitetura de lakehouse, vale primeiro revisar nosso guia completo de Power BI para empresas no Brasil, que cobre o contexto de licenciamento e adoção que precede qualquer decisão sobre Fabric.

OneLake: a peça que sustenta toda a promessa#

O componente central do Microsoft Fabric é o OneLake, uma camada de armazenamento única, baseada em Azure Data Lake Storage Gen2, compartilhada por todos os workloads da plataforma. A ideia é simples de enunciar e difícil de subestimar: em vez de cada ferramenta (warehouse, lakehouse, BI, ciência de dados) manter sua própria cópia dos dados, tudo é gravado uma vez em formato Delta Parquet dentro do OneLake e lido por qualquer workload que precise dele.

Na prática, isso significa:

• Um pipeline de Data Factory grava dados brutos no OneLake.
• Um notebook Spark processa e grava uma camada tratada, ainda no OneLake.
• Um Warehouse SQL lê essa mesma camada sem duplicar dados.
• O Power BI consome o resultado final via Direct Lake, sem precisar de um processo de importação separado.

Esse modelo elimina boa parte do "ETL para BI" que hoje consome tempo de engenharia — a exportação de dados do lake para um modelo tabular otimizado para consulta. É relevante porque uma fração enorme do trabalho de qualquer equipe de engenharia de dados é justamente mover e duplicar dados entre sistemas que não conversam nativamente. O OneLake não elimina esse trabalho por completo, mas reduz o número de saltos.

O ponto de atenção: OneLake resolve duplicação dentro do ecossistema Fabric. Se sua empresa já tem dados espalhados em Snowflake, Databricks, sistemas legados on-premises e SaaS diversos, o Fabric não faz esses sistemas desaparecerem — ele se torna mais um destino, a menos que exista um plano deliberado de consolidação.

Lakehouse x Warehouse: dois motores, um mesmo dado#

Um dos pontos que mais gera confusão em quem avalia o Fabric é a diferença entre os itens "Lakehouse" e "Warehouse" dentro da plataforma. Ambos guardam dados no mesmo OneLake, em formato Delta, mas atendem perfis de uso diferentes.

Característica	Lakehouse	Warehouse
Motor de consulta	Spark (PySpark, Scala, SQL)	T-SQL puro
Público típico	Engenheiros e cientistas de dados	Analistas e times acostumados a SQL Server
Transformação de dados	Notebooks, Spark jobs, Dataflows Gen2	Stored procedures, views, T-SQL
Escrita de dados	Spark, pipelines, shortcuts	T-SQL (INSERT/CREATE TABLE AS)
Formato de armazenamento	Delta Parquet	Delta Parquet (mesmo motor por trás)
Melhor cenário de uso	Dados semi-estruturados, ciência de dados, cargas em escala	Modelagem dimensional, relatórios corporativos, equipes de SQL Server

Na prática, muitas empresas usam os dois lado a lado: o Lakehouse para ingestão e processamento pesado, o Warehouse para a camada semântica final que alimenta relatórios. Como ambos compartilham o mesmo OneLake, é possível ler tabelas do Lakehouse a partir do Warehouse (e vice-versa) sem mover dado nenhum — algo que, em arquiteturas tradicionais separadas, exigiria um pipeline de replicação.

Data Factory, notebooks Spark e Real-Time Intelligence: os motores de processamento#

O Fabric reorganiza as capacidades de processamento de dados da Microsoft em quatro experiências principais, além do BI:

Data Factory no Fabric reaproveita o modelo de pipelines do Azure Data Factory clássico — atividades de cópia, orquestração, gatilhos — mas agora operando nativamente sobre o OneLake. Também traz os Dataflows Gen2, uma evolução do Power Query para transformações low-code em escala, úteis para analistas que não escrevem Spark mas precisam preparar dados.

Notebooks e Spark atendem quem precisa de processamento programático — PySpark, Spark SQL, R ou Scala rodando sobre pools de Spark gerenciados pelo Fabric, sem que a empresa precise provisionar cluster. É o equivalente funcional dos pools do Synapse ou de um workspace do Databricks, mas cobrado pela mesma capacidade que sustenta o resto da plataforma.

Real-Time Intelligence é a resposta do Fabric a cenários de streaming e eventos — IoT, logs de aplicação, telemetria — usando KQL (Kusto Query Language) como motor de consulta, o mesmo por trás do Azure Data Explorer. Para empresas que lidam com dados de sensores, cliques em tempo real ou monitoramento operacional, é um workload que antes exigia um serviço Azure separado e agora vive na mesma capacidade e no mesmo workspace.

Power BI com Direct Lake é, para a maioria dos clientes brasileiros que já usam Power BI, a razão mais concreta para prestar atenção no Fabric — e merece uma seção própria.

Direct Lake: por que isso muda a conversa sobre performance no Power BI#

Historicamente, o Power BI oferecia dois modos de conexão: Import, que carrega os dados para dentro do modelo tabular em memória (rápido para consultar, mas exige atualizações agendadas e duplica o dado), e DirectQuery, que consulta a fonte em tempo real (dado sempre atual, mas com performance dependente da fonte e sem o mesmo desempenho de cache do Import).

O Direct Lake é um terceiro modo, exclusivo do Fabric, que lê os arquivos Delta Parquet diretamente do OneLake e os carrega na engine do Power BI sob demanda, por página e por coluna, sem um processo de importação tradicional. O resultado prático:

• Performance de consulta próxima à do modo Import, porque o motor VertiPaq do Power BI ainda faz o trabalho pesado de compressão colunar.
• Dados atualizados quase em tempo real, porque não existe um refresh agendado tradicional — o modelo reflete o estado atual das tabelas Delta no OneLake.
• Eliminação da duplicação de dados entre o lake e o modelo semântico do Power BI, que no modo Import é inevitável.

O ponto que qualquer consultor honesto precisa deixar claro: Direct Lake não é mágica sem contrapartida. Ele exige que os dados já estejam em formato Delta dentro do OneLake, o que significa que a organização precisa ter (ou construir) uma camada de engenharia de dados madura antes de colher esse benefício. Empresas que hoje têm relatórios de Power BI conectados direto a um ERP ou a planilhas não ganham Direct Lake de graça — primeiro precisam levar esses dados para dentro do Fabric.

O modelo de capacidade: como o Fabric é cobrado (e onde ele pode sair caro)#

Diferente do licenciamento por usuário do Power BI Pro/PPU, o Microsoft Fabric é vendido por capacidade computacional compartilhada, medida em Capacity Units (CU) e vendida em SKUs identificados por F, de F2 a F2048 (o número indica a quantidade de CUs).

SKU	CUs	Uso típico	Custo aproximado (pay-as-you-go, mensal)
F2	2	Testes, POCs, times pequenos	~US$ 262
F8	8	Departamento único, cargas leves	~US$ 1.050
F16	16	Múltiplas equipes, cargas moderadas	~US$ 2.100
F64	64	Organização inteira, cargas pesadas (equivalente a Power BI Premium P1)	~US$ 8.400
F128 e acima	128+	Grandes volumes, múltiplos workloads simultâneos	US$ 16.800+

Valores de referência em dólar, região US East, sujeitos a variação cambial e a descontos por reserva (1 ano ou 3 anos, que podem reduzir o custo em até 40%). É essencial cotar no Azure Pricing Calculator com a região e o modelo de compra reais antes de orçar.

O ponto crítico é que a capacidade é compartilhada entre todos os workloads — Data Factory, Spark, Warehouse, Real-Time Intelligence e Power BI competem pelo mesmo pool de CUs. Isso simplifica a governança financeira (um único custo, não um por serviço), mas é arriscado: um job de Spark mal otimizado ou um relatório com DAX ineficiente pode consumir capacidade e afetar outros workloads — o chamado "throttling" acontece quando o consumo excede o limite contratado por tempo prolongado.

Isso muda a conversa de FinOps: em vez de negociar licenças por usuário, a empresa passa a monitorar consumo de CU ao longo do tempo, o que exige instrumentação e, frequentemente, apoio de um parceiro que já passou por esse dimensionamento.

O que muda em relação ao Azure Synapse Analytics#

Para quem já tem investimento em Synapse, a pergunta natural é: isso substitui o que eu tenho? A resposta é "parcialmente, e depende do prazo".

A Microsoft já sinaliza o Fabric como evolução natural do Synapse, mas o Synapse Analytics clássico (SQL Pools dedicados, Spark Pools, Data Factory no workspace Synapse) continua suportado, sem data de descontinuação anunciada. As principais diferenças:

• Modelo de armazenamento: Synapse usa armazenamento próprio por pool (ou Data Lake Storage separado); Fabric centraliza tudo no OneLake.
• Modelo comercial: Synapse Dedicated SQL Pools são cobrados por DWU (Data Warehouse Units) e podem ser pausados; a capacidade do Fabric é contínua e compartilhada entre workloads.
• Integração com Power BI: o Synapse não oferece Direct Lake — a ponte com Power BI passa por Import ou DirectQuery convencional.
• Maturidade: o Synapse é um produto mais antigo, com mais anos de produção em clientes grandes; o Fabric, embora já estável, ainda recebe funcionalidades novas em cadência acelerada, o que também significa mudanças de comportamento entre versões.

Para times que já têm um Synapse funcionando bem, com SQL Pools dedicados estáveis, a migração para Fabric não é urgente. Faz sentido avaliar quando houver necessidade real de Direct Lake, de unificar times de engenharia e BI, ou quando o contrato de Synapse Dedicated estiver perto de renovação — momento natural para comparar custo total.

Fabric x Synapse x Databricks x Snowflake: o cenário real no Brasil#

Não existe vencedor universal aqui — a escolha depende do que a empresa já tem instalado, da maturidade do time de dados e de onde está o resto da stack de nuvem.

Critério	Microsoft Fabric	Azure Synapse	Databricks	Snowflake
Modelo de cobrança	Capacidade compartilhada (CU)	Por serviço (DWU, Spark pools)	Por cluster/DBU, geralmente sobre Azure/AWS/GCP	Por crédito de computação, separado do storage
Integração com Power BI	Nativa, com Direct Lake	Boa, sem Direct Lake	Via conector, sem integração nativa	Via conector, sem integração nativa
Curva de adoção para times Microsoft	Baixa (Power Query, T-SQL, interface familiar)	Média	Alta (foco forte em Spark/notebooks)	Média (SQL, mas ecossistema próprio)
Maturidade em cargas críticas	Média (produto mais recente)	Alta	Alta	Alta
Melhor cenário	Empresas já no ecossistema Microsoft, com Power BI como BI principal	Cargas de warehouse tradicionais já consolidadas	Engenharia de dados avançada, ciência de dados, multi-cloud	Warehouse puro, forte em compartilhamento de dados entre organizações
Lock-in	Alto dentro do Azure/Microsoft 365	Alto dentro do Azure	Médio (roda em múltiplas nuvens)	Médio (multi-cloud, mas formato proprietário)

No mercado brasileiro, a decisão pende para o Fabric quando a empresa já usa Power BI como padrão de BI, já está no Microsoft 365/Azure e quer reduzir fornecedores. Pende para Databricks ou Snowflake quando o time de engenharia é mais maduro tecnicamente, há necessidade de portabilidade entre nuvens, ou quando ciência de dados e machine learning em escala já são o centro da operação.

Quando migrar para o Fabric agora — e quando esperar#

Migre agora se:

• Sua empresa já usa Power BI Premium ou Premium Per User e paga por uma capacidade que pode ser convertida diretamente em Fabric.
• Existe dor real de performance ou de duplicação de dados entre o data warehouse e os modelos do Power BI — Direct Lake resolve isso de forma direta.
• O time de engenharia já trabalha (ou está disposto a trabalhar) com Delta Lake, Spark e pipelines modernos.
• Há um projeto novo de plataforma de dados começando do zero — nesse caso, começar direto em Fabric evita retrabalho de migrar depois.

Espere se:

• Seu Synapse ou seu data warehouse atual funciona bem, está estável e não há dor de negócio evidente — migração por modismo custa caro e não tem retorno claro.
• O time de dados ainda está consolidando práticas básicas de engenharia (versionamento, qualidade de dado, modelagem) — o Fabric não resolve maturidade organizacional, só dá ferramentas melhores para quem já tem processo.
• A capacidade mínima viável (F64, para a maioria dos cenários corporativos reais) ainda não cabe no orçamento e o uso ficaria limitado a SKUs pequenos demais para representar a carga real de produção.
• Existe dependência forte de múltiplas nuvens (AWS, GCP) que tornaria o lock-in do Fabric um risco estratégico.

Antes de decidir, vale entender como a arquitetura de destino se compara à ferramenta que você usa hoje — inclusive se você vem de outra plataforma de BI, como descrevemos em como migrar de Qlik ou Tableau para Power BI. É uma migração de ferramenta de visualização, não de plataforma de dados, mas compartilha boa parte da lógica de avaliação de custo-benefício.

Perguntas frequentes#

O Microsoft Fabric substitui o Power BI? Não. O Power BI continua sendo o produto de visualização e modelo semântico; o Fabric é a plataforma de dados por trás dele, incluindo o Direct Lake. Quem já usa Power BI Premium, na prática, já paga por capacidade Fabric, mesmo sem usar os outros workloads.

Preciso migrar do Synapse assim que possível? Não. O Synapse Analytics continua suportado, sem data de descontinuação anunciada. A migração faz sentido quando há motivo concreto — Direct Lake, unificação de times ou renovação de contrato — não por antecipação de uma obsolescência ainda indefinida.

Quanto custa começar com Microsoft Fabric? O SKU de entrada (F2) custa algumas centenas de dólares mensais em pay-as-you-go, adequado para provas de conceito. Cargas de produção corporativa costumam exigir F64 ou acima, já na casa de milhares de dólares mensais — por isso o dimensionamento correto é decisivo antes de assinar qualquer contrato.

O Fabric funciona bem com dados fora do Azure? Parcialmente. O Fabric tem conectores e "shortcuts" que apontam para dados externos sem copiá-los, incluindo S3 e ADLS de outras assinaturas, mas a integração mais profunda — como Direct Lake — depende dos dados estarem fisicamente no OneLake. Ambientes fortemente multi-cloud sentem mais atrito.

Fabric é mais barato que manter Synapse e Power BI Premium separados? Depende do padrão de uso. Empresas que já pagam Power BI Premium e mantêm um Synapse subutilizado em paralelo podem reduzir custo total ao consolidar numa única capacidade. Quem usa o Synapse intensamente e o Power BI num plano modesto precisa simular a capacidade real, não supor.

Vale a pena migrar só pelo Direct Lake? Se o problema é performance de relatórios grandes ou duplicação entre warehouse e modelo do Power BI, sim, é motivo legítimo e mensurável. Se o Power BI atual já responde bem, o retorno é menor e a migração pode esperar por uma dor mais concreta.

O Fabric é uma decisão de arquitetura, não de modismo#

O Microsoft Fabric é uma plataforma sólida e, para quem já vive no ecossistema Microsoft, tende a ser o caminho de menor atrito para consolidar engenharia de dados e BI num único lugar. Mas não é gratuito, não é simples de dimensionar e não substitui maturidade de processo — só amplifica o que já existe, para o bem ou para o mal.

A decisão certa depende de onde seus dados estão hoje, de quanto sua equipe já trabalha com Delta Lake e Spark, e de quanto custa, na prática, a capacidade que sua carga real exige. Isso não se resolve numa página de marketing, mas com um diagnóstico da sua arquitetura atual, comparando o custo real de ficar onde está com o custo real de migrar.

Se você quer avaliar se o Fabric faz sentido para o seu cenário — ou entender como estruturar a camada de engenharia de dados que sustente essa decisão — para uma conversa direta sobre o seu caso, fale com a gente.