O exame DP-300 pergunta qual nível de serviço é mais adequado para uma determinada carga de trabalho — não apenas como os níveis se chamam, mas quais são as trocas que cada um implica. Do modelo de compra (DTU vs vCore) ao nível de computação (Provisioned vs Serverless) e ao Elastic Pool, cada opção existe por uma razão concreta.
DTU vs vCore: Pacote fechado vs configuração sob medida
Pense no modelo DTU como um prato feito em um restaurante: CPU, memória e I/O vêm empacotados em um único número. A cobrança é simples e previsível, sem necessidade de ajustar parâmetros individuais. O modelo DTU oferece três camadas de serviço — Basic, Standard e Premium — que escalam juntas conforme o número de DTU aumenta.
O modelo vCore é o oposto: você escolhe a quantidade de núcleos de CPU, a memória e o armazenamento de forma independente. Essa granularidade permite dizer "preciso de mais núcleos, mas menos armazenamento". Também é possível trazer licenças existentes do SQL Server por meio do Azure Hybrid Benefit para reduzir custos. Os três níveis de serviço do vCore são General Purpose, Business Critical e Hyperscale.
O sinal-chave no exame: Azure Hybrid Benefit ou controle independente de recursos indica vCore. Cobrança simples e previsível indica DTU.
General Purpose: o armazém polivalente
Quando uma empresa de logística precisa de um novo armazém para carga geral — sem câmaras frigoríficas nem instalações para materiais perigosos — ela aluga um espaço padrão. Capacidade suficiente, custo razoável. General Purpose é esse armazém padrão para o Azure SQL Database.
General Purpose usa o Azure Premium Storage (SSD remoto) e suporta até 8.000 IOPS. A alta disponibilidade é gerenciada por meio de replicação de armazenamento e failover automático, embora o processo de failover possa levar entre 20 e 30 segundos.
General Purpose não oferece suporte a In-Memory OLTP. Para cargas de trabalho que exigem altíssimo volume de transações — como sistemas de negociação financeira — Business Critical é a escolha certa.
Business Critical: SSD local e AlwaysOn
A torre de controle de um aeroporto não pode se dar ao luxo de ter uma conexão de rede lenta. Dados de radar e movimentos de voo precisam de respostas instantâneas, sempre. Business Critical é essa camada sempre ativa e de baixa latência para o Azure SQL Database.
Business Critical armazena dados em SSD local em vez de armazenamento remoto, o que resulta em menor latência e IOPS significativamente mais altos em comparação com General Purpose. Internamente, executa um cluster de quatro nós baseado em AlwaysOn Availability Group (AG). Um desses nós secundários fica disponível como ponto de conexão somente leitura — um recurso chamado Read Scale-Out.
O Read Scale-Out não tem custo adicional. Direcionar consultas de relatórios para a réplica secundária reduz a pressão sobre o nó primário sem pagar por uma réplica separada. In-Memory OLTP também é suportado no Business Critical. Quando uma carga de trabalho precisa de alto throughput transacional, baixa latência de leitura e fortes garantias de disponibilidade, Business Critical é a resposta.
Hyperscale: paredes que se expandem sozinhas
Bancos de dados tradicionais são como armazéns de tamanho fixo: quando ficam cheios, é preciso se mudar. O Hyperscale derruba esse teto. O armazenamento escala automaticamente até 100 TB conforme os dados crescem, sem intervenção manual.
O Hyperscale usa uma arquitetura única baseada em Page Servers que gerenciam o armazenamento de forma independente da camada de computação. Escalar a computação para cima ou para baixo leva minutos em vez de horas. Os backups são baseados em snapshots, portanto o tempo de backup não cresce proporcionalmente ao tamanho dos dados.
A restrição crítica: uma vez que um banco de dados é migrado para o Hyperscale, ele não pode ser rebaixado para General Purpose ou Business Critical. É uma porta de sentido único. Escolha Hyperscale apenas quando o volume de dados realmente exigir.
!Níveis de serviço do Azure SQL
Serverless vs Provisioned: pague apenas pelo que usar
Alguns escritórios mantêm o ar-condicionado ligado 24 horas; outros usam um termostato inteligente que o desliga quando o prédio está vazio e o reativa quando alguém chega. A computação Provisioned é o modelo sempre ativo. Serverless é o termostato inteligente.
Serverless está disponível apenas na camada General Purpose com o modelo vCore. Ele suporta auto-pause — o banco de dados é suspenso após um período de inatividade configurável — e auto-resume. A cobrança é por segundo de atividade, portanto um banco de dados de desenvolvimento inativo à noite praticamente não gera custos.
A desvantagem é a latência de cold start. Quando o banco de dados retoma de um estado pausado, a primeira solicitação pode esperar de alguns segundos a mais de um minuto. Para cargas de trabalho de produção que precisam de tempos de resposta consistentes, Provisioned é a escolha certa.
Elastic Pool: a piscina compartilhada do hotel
A piscina de um hotel atende dezenas de hóspedes sem que cada um precise da sua própria. Funciona porque nem todos nadam ao mesmo tempo. O Elastic Pool aplica a mesma lógica a bancos de dados.
Um Elastic Pool permite que vários bancos de dados compartilhem um único conjunto de recursos — baseado em DTU ou vCore. Cada banco de dados pode definir uma alocação mínima garantida e um limite máximo, impedindo que um único tenant consuma todo o pool. Aplicações SaaS onde cada cliente tem seu próprio banco de dados são o caso de uso clássico: todos compartilham um pool e cada um obtém o que precisa quando precisa.
O Elastic Pool é mais eficaz com muitos bancos de dados pequenos que têm uso variável e picos não coincidentes.
Armadilhas ao escolher uma camada
Quando se faz as malas para uma viagem, assumir que tudo pode ser comprado no destino é uma aposta que frequentemente não vale a pena. O Azure SQL Database tem decisões similares de sentido único que são custosas de reverter após a implantação.
A armadilha mais crítica é que a migração para o Hyperscale é uma operação de sentido único. Não há caminho de volta para General Purpose ou Business Critical depois de cruzar essa fronteira. Da mesma forma, Serverless e geo-replication não podem ser usados juntos. Se você escolher Serverless para produção e depois precisar de geo-replication, terá que mudar para Provisioned primeiro.
A migração de DTU para vCore é suportada, mas o contrário não é. O Read Scale-Out do Business Critical é gratuito, mas o General Purpose não tem essa função.
Resumo do Exame
"Controle independente de CPU e armazenamento" -- modelo vCore "Portabilidade de licenças com Azure Hybrid Benefit" -- modelo vCore "Cobrança em pacote simples, Basic/Standard/Premium" -- modelo DTU "Dados em escala de petabytes, escalabilidade instantânea, restauração por snapshot" -- Hyperscale "Rebaixar do Hyperscale" -- não suportado (migração de sentido único) "SSD local, AlwaysOn AG de 4 nós, In-Memory OLTP" -- Business Critical "Réplica somente leitura sem custo adicional" -- Business Critical Read Scale-Out "auto-pause / auto-resume, cobrança por segundo" -- Serverless "Serverless + geo-replication" -- não compatíveis "Vários bancos de dados compartilhando um pool de recursos, tenants SaaS" -- Elastic Pool "Azure Premium Storage remoto, OLTP de uso geral" -- General Purpose
DTU = pacote simples, vCore = controle granular; GP = geral, BC = alto desempenho + SSD local, Hyperscale = escala massiva (sentido único)