Quanto custa o Microsoft Fabric: entenda o modelo de capacity

Quanto custa Microsoft Fabric confunde quem vem do modelo por usuário#

Quem gerencia licenças de BI há alguns anos aprendeu a pensar em custo por cabeça: tantos usuários, tantas licenças, multiplica e pronto. Por isso a pergunta "quanto custa Microsoft Fabric" costuma vir com a expectativa de uma resposta simples, um valor por usuário por mês. E é exatamente aí que a conta trava. O Fabric, anunciado pela Microsoft em 2023, não segue a lógica de licença por usuário para a plataforma de dados. Ele segue a lógica de capacidade: você provisiona um poder de processamento compartilhado e paga por esse poder, não pela quantidade de pessoas que o utilizam.

Essa mudança de modelo gera a maior parte da confusão e do desperdício. Entender como a capacidade é medida, como escolher o tamanho certo, o que é cobrado à parte e onde ficam as armadilhas é a diferença entre um Fabric que cabe no orçamento e um que sangra dinheiro todo mês. Neste artigo, destrinchamos o modelo peça por peça, com uma ressalva importante: os valores em moeda mudam com frequência e variam por região e programa de compra, então qualquer número específico deve ser confirmado na página oficial de preços da Microsoft. Se você ainda avalia se a plataforma faz sentido para o seu cenário, vale ler antes a nossa análise em Microsoft Fabric: o que é e vale a pena em 2026.

Capacidade é o coração do custo, medida em Capacity Units#

O conceito central do Fabric é a capacidade. Em vez de licenciar cada pessoa, você provisiona uma capacidade de computação medida em Capacity Units, abreviadas como CU. A CU é a unidade que representa o poder de processamento disponível para rodar todas as suas cargas de trabalho de dados. Quanto mais CU, mais processamento simultâneo a plataforma aguenta antes de começar a enfileirar tarefas.

O ponto que mais surpreende quem vem do mundo por usuário é que essa capacidade é compartilhada por todas as cargas do Fabric. Data Engineering, Data Warehouse, Data Factory, Real-Time Intelligence, Power BI e as demais experiências consomem da mesma capacidade provisionada. Não existe licença separada para cada função: existe um pool único de CU que atende a tudo. A consequência é direta. Se um pipeline pesado de ingestão roda ao mesmo tempo que muitos usuários abrem relatórios, ambos disputam a mesma capacidade. Planejar o custo do Fabric, portanto, é planejar quanta capacidade o conjunto das suas cargas realmente exige, não somar licenças isoladas.

Essa lógica muda o raciocínio de orçamento. Em vez de "quantas pessoas vão usar", a pergunta passa a ser "quanto processamento simultâneo o meu ambiente precisa sustentar nos horários de pico". É uma conta de carga de trabalho, não de headcount, e por isso dimensionar a capacidade certa depende de medir uso real.

A escada de SKUs vai de F2 a F2048 e você escolhe pela carga real#

A capacidade do Fabric é comercializada em uma escada de SKUs que vai do F2 ao F2048. O número que acompanha a letra F indica a quantidade de Capacity Units daquele SKU: o F2 tem 2 CU, o F64 tem 64 CU, o F2048 tem 2048 CU, e assim por diante ao longo da escala. Quanto maior o número, maior o poder de processamento e, naturalmente, maior o custo daquela capacidade.

A boa notícia dessa escada é que ela permite uma estratégia sensata: começar pequeno e escalar conforme a necessidade real aparece. Não há obrigação de assumir um SKU grande de início. Um piloto pode rodar em um SKU baixo, e a capacidade sobe quando o volume de dados, o número de cargas ou a concorrência de usuários justificarem. Do mesmo modo, se você superdimensionou, é possível descer de SKU. Essa elasticidade é uma das vantagens do modelo de capacidade sobre comprometer-se com hardware fixo.

A tabela abaixo mostra, de forma qualitativa, em que momento cada faixa de SKU costuma fazer sentido. Ela não substitui um dimensionamento técnico baseado em métricas reais, mas serve como ponto de partida para conversar sobre orçamento. Os valores em moeda de cada SKU devem ser confirmados na página oficial de preços da Microsoft.

Momento do projeto	Perfil de carga	Faixa de SKU que costuma fazer sentido
Piloto ou prova de conceito	Poucas cargas, volume de dados baixo, poucos usuários testando	Faixa inicial da escada, próxima ao F2
Produção pequena	Cargas regulares, alguns pipelines, times de negócio consumindo relatórios	Faixa intermediária baixa da escada
Produção de médio porte	Múltiplas cargas concorrentes, engenharia de dados ativa, volume crescente	Faixa que atravessa o F64, considerando o limiar de licenciamento
Produção grande	Alta concorrência, muitos consumidores, cargas pesadas em paralelo	Faixa superior da escada, F64 e acima

Repare que o F64 aparece como referência recorrente. Ele não é apenas mais um degrau: é o ponto em que o modelo de licenciamento do Power BI muda, como detalhamos adiante. Por isso merece atenção especial na escolha do SKU.

Pay-as-you-go e reserva anual atendem perfis de uso diferentes#

Escolhido o tamanho da capacidade, vem a segunda decisão de custo: o modelo de compra. O Fabric oferece basicamente dois caminhos. O primeiro é o pay-as-you-go, no qual você paga pela capacidade conforme ela é provisionada e utilizada, com flexibilidade total para ligar, desligar e ajustar. O segundo é a capacidade reservada, na qual você se compromete com um período, tipicamente uma reserva de um ano, em troca de uma condição mais vantajosa. Segundo o próprio modelo comercial da Microsoft, a reserva de um ano costuma sair mais barata do que a mesma capacidade sob demanda, justamente porque você troca flexibilidade por compromisso.

A escolha entre os dois não é qual é melhor em absoluto, e sim qual encaixa no seu padrão de uso. Se a carga é estável, roda o ano inteiro e você já validou o dimensionamento, a reserva anual tende a reduzir o custo total. Se a carga ainda é incerta, se você está em piloto, ou se o uso é sazonal e intermitente, o pay-as-you-go preserva a liberdade de não pagar por capacidade que você não vai usar. Muitas organizações começam sob demanda e migram para reserva quando o consumo se estabiliza. A diferença exata de preço entre os dois modelos deve ser verificada na página oficial de preços da Microsoft, pois varia por SKU e região.

Pausar a capacidade quando ela não roda é a economia mais esquecida#

Aqui está um dos recursos mais subaproveitados do modelo de capacidade: o pause e resume. No pay-as-you-go, você pode pausar a capacidade quando ela não está sendo usada e retomá-la depois. Enquanto está pausada, a cobrança de computação daquela capacidade não corre. Isso abre uma janela de economia enorme para cenários em que o ambiente não precisa ficar de pé 24 horas por dia, 7 dias por semana.

Pense em um ambiente de desenvolvimento e testes usado só em horário comercial, ou em uma capacidade dedicada a processamento noturno que fica ociosa durante o dia. Deixar essa capacidade rodando o tempo todo é pagar por horas em que nada acontece. Pausar nos períodos ociosos e retomar quando necessário reduz o custo de computação de forma proporcional ao tempo desligado. Vale lembrar que o pause afeta a computação: o armazenamento no OneLake, que veremos a seguir, segue cobrado à parte mesmo com a capacidade pausada, porque os dados continuam existindo no lake. Ainda assim, para ambientes sem exigência de disponibilidade contínua, o pause e resume é uma das alavancas de economia mais diretas e mais esquecidas do modelo.

Computação e armazenamento OneLake são cobrados separadamente#

Um dos pontos que mais confunde no orçamento do Fabric é a separação entre computação e armazenamento. A capacidade que discutimos até aqui, medida em CU, é a camada de computação. Ela paga pelo processamento das cargas. O armazenamento dos dados, por outro lado, acontece no OneLake, o data lake unificado do Fabric, e é cobrado à parte da capacidade de computação.

O OneLake é onde os dados ficam guardados, em formato aberto, e é a fundação sobre a qual as cargas do Fabric operam. Recursos como o Direct Lake leem arquivos Parquet e Delta diretamente do OneLake para servir os modelos do Power BI sem duplicar os dados. Mas isso não muda a estrutura de custo: você paga a computação pela capacidade e o armazenamento pelo volume guardado no lake. São duas linhas de custo distintas que se somam.

A tabela a seguir resume os componentes que compõem o custo total de um ambiente Fabric. Entender que são blocos separados evita a armadilha de olhar só para o preço do SKU e esquecer as outras linhas.

Componente	O que é	Como é cobrado
Capacidade de computação	O poder de processamento em CU que roda todas as cargas do Fabric	Por SKU (F2 a F2048), em pay-as-you-go ou reserva anual
Armazenamento OneLake	O volume de dados guardado no data lake unificado	À parte da capacidade, pelo volume armazenado
Licenças Power BI	O direito de consumir conteúdo Power BI conforme o SKU da capacidade	Depende do limiar F64, detalhado na próxima seção

Modelar o custo do Fabric significa somar esses blocos, não olhar só para o valor da capacidade. Uma boa estruturação de dados no lake impacta tanto o armazenamento quanto a eficiência da computação, e é aqui que uma engenharia de dados bem feita se paga ao longo do tempo.

O limiar F64 muda o jogo do licenciamento Power BI#

Se existe um número mágico no modelo de custo do Fabric, é o F64. Ele determina como o consumo de conteúdo Power BI é licenciado sobre a capacidade, e o impacto no orçamento pode ser enorme dependendo de quantas pessoas apenas leem relatórios na sua organização.

A regra funciona assim. Para consumir relatórios Power BI publicados em uma capacidade Fabric abaixo de F64, cada usuário que visualiza o conteúdo ainda precisa de uma licença Power BI Pro individual. Ou seja, na faixa abaixo do F64, você paga a capacidade e ainda paga Pro por cabeça para quem consome. A partir do F64, o consumo de conteúdo Power BI é liberado sem a necessidade de licença Pro por usuário, comportamento equivalente ao do antigo Power BI Premium por capacidade. Nessa faixa, os consumidores que só leem relatórios não precisam de licença individual.

A consequência é direta. Em organizações com muitos consumidores de leitura, pessoas que abrem dashboards para acompanhar indicadores mas nunca criam nada, o F64 pode virar o ponto em que assumir a capacidade sai mais barato do que multiplicar licenças Pro. Quanto maior a proporção de leitores em relação a criadores, mais forte é esse argumento. Já em times pequenos com poucos consumidores, pode não fazer sentido saltar para o F64 só pelo licenciamento. É uma conta que precisa considerar o mix real de usuários. O limiar vigente e a regra exata devem ser confirmados na página oficial de preços da Microsoft, pois esse tipo de política é revisado periodicamente. Se a sua decisão gira em torno de licenciamento de Power BI e dimensionamento de capacidade, vale aprofundar em serviços de Power BI e em como estruturamos dashboards que sustentam esse consumo em escala.

Os erros de custo mais comuns são superdimensionar e deixar rodando 24x7#

Depois de entender o modelo, os erros de custo ficam previsíveis, e quase todos giram em torno de dois hábitos herdados do mundo antigo. O primeiro é superdimensionar a capacidade. Por medo de lentidão ou enfileiramento de tarefas, muita gente assume um SKU maior do que a carga exige, e paga capacidade ociosa todo mês. Como a escada permite subir quando necessário, começar conservador e escalar sob evidência de uso costuma ser mais barato do que comprar folga que talvez nunca seja consumida.

O segundo erro é deixar a capacidade rodando 24 horas por dia, 7 dias por semana, quando o negócio não precisa disso. Ambientes de desenvolvimento, testes e cargas que só rodam em janelas específicas não exigem disponibilidade contínua. Ignorar o pause e resume nesses casos é jogar dinheiro fora em horas ociosas. A economia aqui não depende de negociar preço: depende de desligar o que não está em uso.

Há ainda erros derivados desses dois. Esquecer que o armazenamento OneLake é uma linha de custo separada faz o orçamento parecer menor do que é. E ignorar o limiar F64 leva organizações a pagarem licenças Pro que a capacidade certa dispensaria, ou a saltarem para o F64 sem volume de leitores que justifique. Evitar esses erros é questão de medir o uso real antes de decidir e revisar o dimensionamento conforme a plataforma cresce. É esse trabalho de arquitetura e governança de custo que conecta as soluções de dados ao resultado financeiro esperado.

Perguntas frequentes#

Quanto custa Microsoft Fabric por usuário? O modelo do Fabric não responde a isso diretamente, porque a plataforma de dados não é cobrada por usuário. O custo é baseado em capacidade, medida em Capacity Units, provisionada em SKUs de F2 a F2048. O que existe por usuário é o licenciamento de consumo do Power BI, e mesmo esse depende do limiar F64. Para valores em moeda, consulte a página oficial de preços da Microsoft.

O que são Capacity Units e por que elas definem o preço? Capacity Units, ou CU, são a unidade que mede o poder de processamento de uma capacidade Fabric. O número no nome do SKU indica a quantidade de CU: o F2 tem 2 CU, o F64 tem 64 CU. Como todas as cargas compartilham a mesma capacidade, é a quantidade de CU que determina quanto processamento simultâneo o ambiente sustenta, e por isso ela está no centro do custo.

Vale mais a pena pay-as-you-go ou capacidade reservada? Depende do padrão de uso. O pay-as-you-go dá flexibilidade para ligar, desligar e ajustar, ideal para pilotos e cargas incertas ou sazonais. A reserva de um ano costuma sair mais barata que a mesma capacidade sob demanda, valendo quando a carga já é estável. Muitas organizações começam sob demanda e migram para reserva quando o consumo se estabiliza.

O armazenamento no OneLake está incluído na capacidade? Não. A capacidade em CU paga a computação que roda as cargas. O armazenamento no OneLake é cobrado à parte, pelo volume guardado no data lake. São duas linhas de custo distintas que se somam. Mesmo com a capacidade pausada, o armazenamento segue cobrado, porque os dados continuam existindo no lake.

Preciso de licença Power BI Pro se já tenho capacidade Fabric? Depende do SKU. Para consumir conteúdo Power BI em uma capacidade abaixo de F64, cada usuário que visualiza relatórios ainda precisa de licença Pro individual. A partir do F64, o consumo é liberado sem Pro por usuário, como no antigo Premium por capacidade. O limiar vigente deve ser confirmado na página oficial de preços da Microsoft.

Como evitar pagar demais pelo Fabric? Os dois maiores desperdícios são superdimensionar a capacidade e deixá-la rodando sem necessidade. Comece com um SKU conservador e escale sob evidência de uso real, use o pause e resume para desligar ambientes ociosos, e considere o limiar F64 no dimensionamento para não pagar licenças Pro que a capacidade certa dispensaria. Medir uso antes de decidir evita a maior parte do gasto excedente.

O custo do Fabric é gerenciável quando o modelo é entendido#

Quanto custa o Microsoft Fabric não tem resposta de tabela única, e isso é uma boa notícia depois que o modelo fica claro. O custo é a soma de capacidade de computação, armazenamento no OneLake e licenciamento de consumo conforme o limiar F64, com alavancas concretas de economia em cada bloco: escolher o SKU certo, decidir entre sob demanda e reserva, e pausar o que não roda. Empresas que dominam esse modelo pagam pelo que usam. As que insistem na lógica antiga por usuário costumam pagar mais e entender menos.

Se você quer dimensionar uma capacidade Fabric para o seu cenário real, sem superdimensionar nem descobrir custos escondidos depois, fale com a Fynx e vamos montar essa conta junto com você.