Azure SQL Database vs. Fabric SQL Database: diferenças de custo e de computação explicadas

By Mirko Peters · 2026-10-21

Compare os custos de computação, o dimensionamento sem servidor, as unidades de capacidade, a economia de armazenamento e os compromissos de recursos entre Azure SQL Database e Fabric SQL Database.

Automatically translated with AI from the original post. Read the English original

Escolher entre Azure SQL Database e Fabric SQL Database depende de entender como a alocação de computação, o comportamento de escalonamento e as unidades de capacidade diferem. Embora ambos sejam executados no mesmo mecanismo SQL robusto, a integração do Fabric com o OneLake e os modelos de capacidade compartilhada introduzem considerações arquiteturais e de custo distintas para organizações orientadas a dados.

Principais conclusões

• O Fabric SQL Database usa unidades de capacidade (CUs) compartilhadas do Fabric, em vez de camadas de vCore do Azure independentes.
• Os recursos de computação são reduzidos a zero e liberados automaticamente após 15 minutos de inatividade, para economizar custos.
• O armazenamento é cobrado continuamente por hora, enquanto o armazenamento de backup é gratuito até o tamanho do seu banco de dados principal.
• O espelhamento automático integrado elimina pipelines ETL manuais, preenchendo arquivos Delta Parquet no OneLake em tempo real.
• O Azure SQL Database tradicional oferece pools elásticos dedicados e tarefas do SQL Server Agent, que os ambientes Fabric tratam de forma diferente.

Entendendo a computação: vCores vs. unidades de capacidade

Ao migrar cargas de trabalho ou planejar uma nova arquitetura em nuvem, a mudança fundamental entre o Azure SQL tradicional e o Fabric SQL está no gerenciamento de computação. Em um Azure SQL Database independente, você provisiona vCores dedicados ou computação sem servidor que se vincula diretamente à sua instância de banco de dados individual. Você gerencia os limites de escalonamento, as janelas de manutenção e as camadas de desempenho em uma base por banco de dados.

Já um Fabric SQL Database extrai seu poder computacional do pool de capacidade mais amplo do Fabric da sua organização. Esse modelo de recurso compartilhado significa que seu banco de dados divide um orçamento com relatórios do Power BI, pipelines do Data Factory e Lakehouses. A conversão entre Unidades de Capacidade do Fabric (CUs) e o poder do banco de dados é feita dinamicamente, nos bastidores. Por exemplo, uma alocação de 64 unidades de capacidade equivale, aproximadamente, a 24,5 vCores para a sua carga de trabalho de banco de dados. Essa abordagem de pool unificado evita a fragmentação de recursos comum em ambientes com vários bancos de dados, permitindo o compartilhamento dinâmico em todo o seu workspace de análise.

Regras de escalonamento sem servidor e de cobrança em ociosidade

Ambas as ofertas de banco de dados usam arquiteturas sem servidor que escalam para cima durante picos de execução de consultas e voltam a reduzir quando o tráfego diminui. No entanto, a mecânica de cobrança do tempo ocioso é especialmente importante para a previsão de orçamento. Um Fabric SQL Database monitora a atividade continuamente. Se um banco de dados ficar completamente ocioso por 15 minutos, sem consultas de entrada, ele libera todos os seus recursos de computação, reduzindo o custo de computação a zero.

Para evitar a latência de inicialização a frio para o próximo usuário, a Microsoft implementa um buffer de retenção deliberado. Se um banco de dados trabalha intensamente por dois minutos e depois fica inativo, você é cobrado por esses dois minutos ativos mais 15 minutos adicionais de computação em espera aquecida, totalizando 17 minutos. Já o armazenamento permanece constante e é cobrado a cada hora, independentemente de o banco de dados estar processando transações ou em repouso.

Custos de armazenamento e economia de backups

A gestão de armazenamento no Fabric SQL Database traz vantagens relevantes de redução de custos em comparação com configurações legadas. Como o banco de dados inicia automaticamente o espelhamento contínuo para o OneLake, os seus registros operacionais são duplicados em arquivos Delta Parquet abertos. Esse formato aberto garante que os seus dados nunca fiquem presos em um silo proprietário, permitindo que qualquer ferramenta capaz de ler o formato Delta consulte a cópia espelhada diretamente.

Além disso, a economia de backups é bastante otimizada no ecossistema do Fabric. Os recursos de restauração pontual permitem que os administradores voltem no tempo em até sete dias para se recuperar de corrupção acidental de dados ou de erros graves de usuários. O armazenamento de backup é totalmente gratuito até o tamanho total do seu banco de dados principal. Você só paga cobranças adicionais se o armazenamento de backup ultrapassar o tamanho do banco de dados ativo, o que oferece uma rede de segurança financeira previsível para a retenção de dados de longo prazo.

Compensações operacionais: o que você ganha e o que perde

Embora o mecanismo SQL principal seja idêntico nas duas plataformas, escolher o Fabric SQL Database em vez do Azure SQL Database exige avaliar trade-offs específicos de recursos. Saber o que falta na implementação do Fabric evita bloqueios arquiteturais inesperados durante o desenvolvimento.

Recursos exclusivos do Azure SQL tradicional

Os bancos de dados Azure SQL independentes oferecem suporte nativo a pools elásticos por nome, dando aos administradores de banco de dados controle granular sobre os agrupamentos de bancos. Eles também incluem o SQL Server Agent clássico, do qual muitas aplicações legadas dependem para agendar stored procedures e tarefas de manutenção internamente.

Vantagens nativas do Fabric SQL

O Fabric SQL elimina a sobrecarga administrativa de configurar pipelines de replicação externos. Assim que você cria o banco de dados, o espelhamento é ativado automaticamente para todas as tabelas compatíveis, sem exigir configuração manual de ETL. Além disso, ele se integra nativamente ao Git para controle de código-fonte e oferece suporte a convenções de nomenclatura de três partes, permitindo unir facilmente tabelas operacionais com Lakehouses e Warehouses em uma única consulta. Para uma visão abrangente de como essas peças se encaixam, ouça o episódio completo e ouça a análise de especialistas e as estratégias práticas para arquitetos de dados modernos.

Perguntas frequentes

Como funciona a cobrança de um Fabric SQL Database ocioso?

A cobrança de computação continua por 15 minutos após o término da última consulta, para manter o banco de dados aquecido; depois disso, os custos de computação caem para zero. O armazenamento continua sendo cobrado por hora, independentemente da atividade.

Preciso configurar o espelhamento manualmente para levar os dados ao OneLake?

Não. O espelhamento começa automaticamente no momento em que o seu Fabric SQL Database é criado, sincronizando continuamente suas tabelas relacionais com o OneLake como arquivos Delta Parquet abertos, sem necessidade de código ETL personalizado.

Posso usar o SQL Server Agent para agendar tarefas em um Fabric SQL Database?

O SQL Server Agent não está disponível no Fabric SQL Database. Em vez disso, a Microsoft recomenda usar pipelines do Data Factory ou tarefas do Apache Airflow para agendamento e automação.

Como os backups são cobrados no Fabric SQL?

Os backups de restauração pontual são totalmente gratuitos até o tamanho total de armazenamento do seu banco de dados ativo. Você só paga pelo armazenamento de backup se a sua área ocupada por backups ultrapassar o tamanho do banco de dados principal.