Azure SQL Database – DTU, vCore, General Purpose, Serverless, Business Critical, Hyperscale, Elastic Pool: Qual escolher?

Fala pessoal! Tudo bem com vocês?

Hoje vamos mergulhar em um dos temas que mais gera dúvida na cabeça de quem está começando a jornada de modernização de dados no Microsoft Azure: a escolha do modelo de compra para o Azure SQL Database.

Se você já abriu o portal do Azure, deve ter se deparado com a sopa de letrinhas: DTU, vCore, Basic, Standard, General Purpose, Single Database, Elastic Pool, Hyperscale, Serverless, Elastic Pool…

A lista é longa e escolher o modelo errado pode significar pagar muito mais caro por um recurso sem necessidade e/ou sofrer com problemas de performance porque o gargalo de IOPS ou CPU está batendo no teto de uma camada de serviços que não foi bem planejada para aquele workload.

Quando o Azure SQL Database surgiu, a Microsoft precisava atingir dois públicos completamente diferentes ao mesmo tempo: desenvolvedores que queriam só um banco funcionando e DBAs acostumados a pensar em CPU, memória, disco e latência e queriam ter flexibilidade para escolher os componentes de hardware do banco de dados.

Neste post, vamos analisar as diferenças técnicas, entender a arquitetura por trás de cada tier e, claro, disponibilizar um script para você saber exatamente qual o equivalente em vCore para o seu banco que hoje roda em DTU.

O que é o Modelo DTU (Database Transaction Unit)?

O modelo baseado em DTU foi o primeiro a ser lançado no Azure SQL Database, e é do tipo Single Database. A ideia da Microsoft era simplificar a vida do DBA e do Desenvolvedor: em vez de você se preocupar com quantos núcleos de processador, quantos IOPS o disco terá ou quanta memória RAM o banco precisa, você compra uma “unidade de medida” que representa o poder computacional.

Uma DTU é uma mistura balanceada de CPU, Memória e Leitura/Escrita de Dados (I/O) baseado em um benchmark interno da Microsoft que simula um workload OLTP genérico, com leitura, escrita, uso de CPU e geração de log de transações.

Quando você compra DTUs, você não está comprando CPU, nem memória, nem IOPS individualmente. Você está comprando uma fatia desse pacote fechado.

Na prática, isso significa que se sua aplicação for CPU-bound, você vai bater no limite de CPU antes de qualquer outra coisa. Se for I/O-bound, vai bater em IOPS. Se for log-heavy, o gargalo aparece como WRITELOG. E o pior: você não tem como realocar recursos dentro do pacote. Se sobra memória mas falta CPU, você terá que aumentar o tier do banco, que irá aumentar CPU, memória e disco, mesmo que não precise aumentar a memória e o disco, por exemplo.

Níveis de Serviço no Modelo DTU

• Basic: É o tier mais simples possível, que custa mensalmente USD 4.90, onde o limite de tamanho do banco de dados é de apenas 2 GB e o poder de processamento é mínimo. Foi pensado para cenários extremamente leves, provas de conceito, demos e aplicações muito pequenas. IOPS são baixíssimos, a latência é alta e qualquer pico de carga vira gargalo rapidamente. Não é um tier para produção séria.
• Standard: É aqui que a maioria das empresas começa, onde o custo mensal começa em USD 17.81 com até 250 GB de armazenamento (tier S0) e pode escalar até um custo mensal de USD 5606.43 com 1 TB de armazenamento (tier S12). Neste tier, se você alocar 1 GB ou 250 GB, vai pagar exatamente o mesmo valor. A partir de 250 GB, o que passar deste tamanho, é cobrado. Oferece uma performance previsível para aplicações pequenas e médias e projetos pequenos de dados. O armazenamento continua sendo remoto, o log pode virar gargalo facilmente e workloads mais agressivos começam a sofrer com latência de I/O e WRITELOG.
• Premium: Focado em aplicações de missão crítica, onde o custo mensal começa em USD 552.12 com até 500 GB de armazenamento já incluso (tier P1), podendo chegar até USD 19081.25 e armazenamento de 4 TB (tier P15). No Business Critical, você tem IOPS significativamente mais altos e de baixa latência (SSD local) e suporte a Read Scale-Out (uma réplica de leitura gratuita) para consultas pesadas e relatórios sem gerar impacto no nó primário onde roda a aplicação. Premium DTU e Business Critical vCore usam arquiteturas muito semelhantes.

Na camada de serviço DTU, o banco utiliza redundância local de hardware (LRS), com SLA típico de 99,99%, onde seu banco tem réplicas no mesmo datacenter, mas se houver alguma indisponibilidade nesse datacenter, o seu banco ficará indisponível.

O que é o Modelo vCore (Virtual Core)?

O modelo vCore, que também é do tipo Single Database, surgiu para dar transparência. Ele é muito mais próximo do que estamos acostumados no ambiente On-Premises. Nele, você escolhe especificamente a geração do hardware, a quantidade de núcleos virtuais (vCores) e a quantidade de memória é vinculada a essa escolha (geralmente uma razão fixa por core).

Com vCore, você consegue entender exatamente se o banco é CPU-bound, memory-bound ou I/O-bound. Consegue planejar crescimento, estimar custos, comparar com on-premises e, principalmente, justificar tecnicamente cada centavo gasto. Em contrapartida, você perde a simplicidade do DTU e assume a responsabilidade de arquitetar corretamente.

A grande vantagem aqui, além da transparência, é a possibilidade de utilizar o Azure Hybrid Benefit (AHB), que permite usar suas licenças de SQL Server que você já possui (com Software Assurance) para pagar muito menos no PaaS.

Níveis de Serviço no Modelo vCore

• General Purpose: Camada de entrada para o vCore e ideal para aplicações corporativas comuns, desde que não sejam muito sensíveis à latência de I/O. O custo mensal inicial vai de USD 568.48 com 2 vCores 1 GB de armazenamento, expansível até 1 TB e pode chegar a USD 37483.51 com 128 vCores e 4 TB de armazenamento. O armazenamento e a computação são separados. O log de transações e os dados ficam no Azure Premium Storage, o que pode gerar uma latência de IO um pouco maior em comparação ao Business Critical.
• General Purpose (Serverless): Variante do General Purpose onde a computação escala automaticamente conforme a utilização, permitindo auto-pause do banco quando ocioso e cobrança por vCore por segundo. Ideal para workloads intermitentes, ambientes de desenvolvimento, QA e aplicações com uso esporádico, reduzindo drasticamente o custo quando o banco não está sendo utilizado. Possui cold start na retomada e não é indicado para sistemas OLTP críticos ou workloads 24×7.
• Business Critical: Alta performance e alta disponibilidade, com custos mensais iniciando em USD 1392.62 para 1 GB de armazenamento, podendo chegar até USD 91520.22 por mês, com 128 vCores e 4 TB de armazenamento. Assim como no Premium (DTU), os dados ficam em SSDs locais (NVMe), garantindo latência baixíssima e replica os dados internamente via Always On em 3 réplicas, além de suporte a Read Scale-Out, onde 1 das 3 réplicas locais permite leituras para executar consultas pesadas e relatórios sem gerar impacto no nó primário onde roda a aplicação. Ideal para bancos com alto volume de WRITELOG e é o tier certo para sistemas críticos, OLTP pesado e bancos que sofrem com WRITELOG e PAGEIOLATCH.
• Hyperscale: A arquitetura mais moderna, com custos mensais inicias em USD 506.70 para 1 réplica de alta disponibilidade, podendo chegar até USD 101339.77 por mês, com 80 vCores e 4 réplicas de alta disponibilidade. Permite bancos de até 128 TB em Single Database (e 100 TB em Elastic Pool). Ele separa o motor de query do motor de armazenamento, permitindo um escalonamento quase instantâneo, independente do tamanho dos dados, permitindo crescimento praticamente ilimitado de dados. Não é automaticamente mais rápido que Business Critical. Ele é melhor quando o problema é tamanho e crescimento, não latência pura.
• Hyperscale (Serverless): Variante do Hyperscale (disponibilidade depende da região) onde a computação escala automaticamente e o banco pode entrar em auto-pause quando ocioso, com cobrança por vCore por segundo. Mantém toda a arquitetura distribuída do Hyperscale (Page Servers + Log Service), permitindo bancos de até 128 TB com custo extremamente reduzido em workloads intermitentes ou com longos períodos de inatividade. Possui cold start na retomada e não é indicado para workloads críticos 24×7 que exigem latência mínima constante.

Comparação gráfica:

Redundância local (LRS) e Redundância por zona (ZRS)

Assim como na camada de serviço DTU, nos modelos vCore, a opção padrão é utilizar redundância local de hardware (LRS), com SLA típico de 99,99%, seu banco tem réplicas no mesmo datacenter, mas se houver alguma indisponibilidade nesse datacenter, o seu banco ficará indisponível.

Diferente do DTU, no vCore também é possível escolher redundância por zona (ZRS), espalhadas em 3 datacenters diferentes (3 zonas de disponibilidade), com SLA de 99,995%. Isso significa que seus dados são armazenados simultaneamente em 3 zonas físicas separadas, cada um com energia, rede e refrigeração independentes. Se um datacenter inteiro cair, o Azure promove outra réplica e sua aplicação continua funcionando.

ZRS oferece SLA maior e tolerância a falhas de datacenter, porém com custo adicional de 10~20%, escritas ligeiramente mais lentas e latência levemente maiores.

Capacidade Reservada (Reserva de vCores)

No modelo vCore é possível contratar reserva de 1 ou 3 anos, reduzindo drasticamente o custo mensal, o que não acontece no modelo DTU.

No vCore você não “aluga por hora para sempre”: Você pode comprar antecipadamente a capacidade de CPU (vCores) por 1 ou 3 anos, e em troca, a Microsoft te dá descontos agressivos sobre o valor do compute, podendo chegar a 33% de desconto com reserva de 1 ano, 55% de desconto na reserva de 3 anos e 70~80% de desconto na reserva de 3 anos + Azure Hybrid Benefit (AHB).

Na prática, você não reserva um banco, você reserva quantos vCores você quiser numa região. Esses vCores ficam como crédito e qualquer Azure SQL vCore que você tiver naquela região passa a consumir esses créditos automaticamente. Ou seja, você não perde flexibilidade e pode mover o banco, trocar tier, escalar e o crédito acompanha.

Comparativo Direto: DTU vs vCore

Para facilitar a sua tomada de decisão, preparei essa tabela comparativa que mostra onde cada modelo brilha:

Azure SQL Database Serverless (vCore Serverless)

O Serverless não é um novo tipo de banco de dados, mas sim um modo especial do modelo vCore, disponível nas camadas General Purpose e Hyperscale, onde a Microsoft gerencia automaticamente a quantidade de CPU ativa, escalando para cima e para baixo de forma dinâmica conforme a carga de trabalho.

Diferente do vCore provisionado, onde você paga por vCores fixos 24×7, no Serverless você paga por CPU utilizada por segundo e por armazenamento, podendo reduzir drasticamente o custo em workloads intermitentes.

Principais Características

• Auto-scale de CPU: O Azure aumenta e reduz automaticamente a quantidade de vCores conforme a utilização real do banco.
• Auto-pause: Se o banco ficar inativo por um período configurável (mín. 1 hora), ele pode ser pausado automaticamente, e você deixa de pagar computação e paga apenas pelo armazenamento dos dados.
• Cold Start: Ao receber uma nova conexão após estar pausado, o banco é reativado automaticamente (30–90s em média).
• Sem downtime ao escalar: O scale up/down ocorre online, sem indisponibilidade.

Custos

• Você paga por segundo de vCore ativo, não por vCore provisionado.
• Durante o auto-pause, você paga apenas pelo armazenamento e backups.
• Ideal para workloads que ficam ociosos boa parte do tempo, como cargas em ambientes D-1 que não tem leituras durante o dia.

Quando vale a pena usar Serverless

• Ambientes de desenvolvimento, homologação e QA.
• Aplicações com uso esporádico (intranet, backoffice, SaaS com poucos acessos).
• APIs com tráfego intermitente.
• Cargas que ficam inativas por longos períodos.
• Projetos com forte preocupação em custo.
• Bancos grandes em Hyperscale que ficam inativos a maior parte do tempo.

Quando NÃO usar Serverless

• Sistemas OLTP críticos e 24×7.
• Workloads sensíveis a latência de conexão (cold start).
• ETLs contínuos ou batch frequentes.
• Bancos que precisam de previsibilidade total de performance.

Alterar a camada de serviço entre DTU e vCore

Important: Há poucas limitações para trocar entre tiers, mesmo de modelos de diferentes (DTU e vCore), ou seja, você pode migrar do DTU Basic pra um vCore Business Critical e depois voltar pra um vCore General Purpose ou DTU Standard, por exemplo.

Entretanto, você precisa ter alguns cuidados.

A Barreira do Tamanho (Max Storage Size)

O primeiro ponto de atenção é o limite físico de armazenamento. Cada tier de serviço possui um teto máximo de GB suportados. Se o seu banco de dados cresceu além do limite do tier de destino, o Azure simplesmente não permitirá o downgrade ou a troca de modelo até que você reduza o volume de dados ou escolha um tier compatível.

Um exemplo clássico: O tier DTU Basic é limitado a 2 GB. Se o seu banco possui 5 GB em um tier Standard S0 e você tentar movê-lo para o Basic para economizar, a operação vai falhar.

Limitação de Recursos de Engine (Features)

Embora o motor do SQL Server seja o mesmo, a Microsoft desabilita algumas funcionalidades dependendo do tier contratado na camada de serviço DTU.

Tiers mais baixos, especificamente o DTU Basic e o Standard nos níveis S0, S1 e S2, possuem restrições em funcionalidades como Columnstore Indexes e In-Memory OLTP (XTP), que não estão disponíveis nesses níveis.

Hyperscale tem regras diferentes

Hyperscale não é só um tier mais alto, ele muda completamente a arquitetura física do banco, onde o banco deixa de existir como um MDF tradicional: Dados vão para storage distribuído, dados são replicados internamente utilizando Log Service + Page Servers ao invés de um AlwaysOn e o banco vira um conjunto de fragmentos distribuídos.

Ao migrar um banco para Hyperscale, você possui uma janela de aproximadamente 45 dias para voltar para General Purpose ou Business Critical mantendo o mesmo banco. Após esse período, o downgrade direto não é mais permitido e o retorno exige estratégia de migração por cópia de dados.

Isso acontece porque a Microsoft mantém temporariamente uma imagem compatível do banco no formato antigo. Durante ~45 dias, o Azure ainda consegue remontar seu banco de volta para GP/BC. Depois disso, o banco é definitivamente convertido para o formato distribuído e a partir desse momento, o MDF tradicional não existe mais.

Depois desses 45 dias, você não consegue mais sair do Hyperscale para outro tier ou camada de serviços, o portal simplesmente bloqueia essa mudança. Se realmente quiser migrar para outra camada de serviço ou tier, você terá que criar um novo banco e migrar os dados, utilizando BACPAC, Replicação, SQLPackage ou outra ferramenta.

Tabela de Disponibilidade de Recursos (Modelo DTU)

Para facilitar, montei essa tabela rápida para você não errar na hora de planejar o tier:

Script de Verificação de Itens Impeditivos

Para não ser pego de surpresa, preparei um script que você deve rodar no seu banco ANTES de tentar qualquer downgrade para tiers baixos. Ele verifica se existem objetos que impedem a ida para o mundo do DTU Basic/Standard de entrada.

Quando DTU faz sentido

DTU faz sentido quando simplicidade é mais importante que controle. Ambientes pequenos, aplicações simples, times sem DBA dedicado ou cenários onde o banco não é crítico costumam se beneficiar do modelo DTU. Ele reduz decisões, reduz erro humano e entrega algo bom o suficiente sem exigir conhecimento profundo de arquitetura.

Em termos práticos, quando você está iniciando um novo projeto, começar no DTU faz muito sentido, pois você consegue começar com um valor muito baixo e ir escalando para os próximos tiers conforme a necessidade. A partir do tier S6, o custo já chega a USD 712.44 e a migração para o modelo de vCore já passa a fazer mais sentido que manter no DTU.

Quando migrar de DTU para vCore?

A pergunta de um milhão de dólares! Na minha experiência, os sinais de que você deve sair do DTU e ir para o vCore são:

• Pressão de Memória (Memory-bound): Se você sofre com waits como RESOURCE_SEMAPHORE, spill de operadores (Hash/Sort) ou degradação de cache e o DTU já está alto. No vCore você passa a controlar a razão de memória por núcleo, algo impossível no DTU.
• Latência de Storage (IO-bound): Se você observa waits recorrentes como PAGEIOLATCH_SH, WRITELOG ou LOG_RATE_GOVERNOR. No vCore Business Critical ou DTU Premium, os dados e o log ficam em SSD NVMe local, reduzindo drasticamente a latência de leitura e escrita, mas o vCore BC pode ter um custo x benefício melhor.
• Custo de Licenciamento: Se sua empresa já possui licenças de SQL Server com Software Assurance, o vCore permite utilizar o Azure Hybrid Benefit e reduzir o custo mensal em até 55% (ou até ~80% combinando com reservas).
• Previsibilidade de Throughput e ETL: Se você precisa garantir taxa de log (MB/s), IOPS ou throughput estável para cargas de ETL, integrações ou processos batch que hoje sofrem com governança interna do DTU.
• Tamanho e Crescimento do Banco: Se seu banco começa a se aproximar de 300–500 GB, ou caminha para o limite de 1 TB dos tiers Standard, o vCore passa a ser a escolha natural por permitir crescimento de storage independente e acesso ao Hyperscale.
• Alta Disponibilidade Real (ZRS): Se o banco é crítico e precisa sobreviver à queda de um datacenter inteiro, apenas o vCore permite Zone Redundant Storage (ZRS) com SLA de 99,995%.
• Escala massiva de dados (Hyperscale): Apenas vCore permite bancos acima de 4 TB, chegando a até 128 TB com scale-out de leitura e restores quase instantâneos.
• Paralelismo real e controle de CPU: vCore fornece CPU e maxDOP reais, evitando os limites rígidos e imprevisíveis do DTU.

Script T-SQL para comparar o tier DTU vs vCore do banco Azure atual

Muitos DBAs ficam perdidos na hora de converter “X DTUs” para “Y vCores”. Para resolver isso, preparei um script que analisa as DMVs do seu banco atual e sugere a configuração de vCore e DTU baseada no hardware que você está rodando no Azure.

Como o DTU esconde CPU, memória e I/O dentro de um pacote fechado, o Azure não te diz claramente quanto de hardware você realmente tem por trás. Esse script abre a caixa-preta do DTU e traduz o seu banco atual para números reais de infraestrutura.

Esse script estima quantos “cores lógicos” o seu banco possui hoje, quanta memória total o banco realmente tem disponível e em qual geração de hardware (Gen4 ou Gen5) o banco está rodando. A partir disso, ele gera De x Para que mostra quantos vCores seriam necessários para chegar a algo equivalente no modelo vCore, e não apenas em um hardware, mas em várias famílias diferentes: Gen4, Gen5, Fsv2 (CPU-bound) e M-Series (memory-bound). Para cada uma delas, o script já estima também quanta memória aquele ambiente teria, facilitando a escolha da família correta.

Por fim, o script ainda sugere qual tier vCore faz mais sentido arquiteturalmente para o seu banco (General Purpose, Business Critical ou Hyperscale), baseado no tier DTU atual, servindo como um guia inicial de migração.

Análise de Performance e Wait Types

Ao monitorar a performance no Azure SQL Database, independentemente do modelo, você deve estar atento aos Wait Types. Eles são a bússola do DBA.

• INSTANCE_AND_RESOURCES_GOVERNOR: Se você vir esse wait type, o Azure está limitando seu banco por causa do tier contratado. É o sinal claro de que você precisa de um upgrade (mais DTUs ou mais vCores).
• LOG_RATE_GOVERNOR: Indica que você atingiu o limite de taxa de transferência de log de transações. No vCore, cada tier tem um limite de MB/s de log. Se o seu processo de INSERT/UPDATE em massa está lento, o gargalo pode estar aqui.
• WRITELOG: Comum em tiers Standard ou General Purpose, onde o armazenamento não é local. Se esse tempo de espera for alto, considere migrar para Premium ou Business Critical.

O Azure SQL Database não oferece recursos ilimitados. Cada tier possui limites internos de CPU, IO, taxa de log, sessões e workers. Ao atingir esses limites, o motor passa a aplicar governança, causando waits como LOG_RATE_GOVERNOR e INSTANCE_AND_RESOURCES_GOVERNOR.

Read Scale-out (Réplica de Leitura Nativa)

Os tiers DTU Premium e vCore Business Critical oferecem o recurso Read Scale-out, que disponibiliza uma réplica de leitura nativa, síncrona e automática, criada pelo próprio Azure SQL Database, sem custo adicional (já incluso no preço, na verdade).

Essa réplica utiliza a arquitetura Always On, mantendo consistência forte (sem lag perceptível) e permitindo descarregar consultas de BI, relatórios, dashboards e APIs de leitura da réplica primária, sem impactar a performance de escrita.

O acesso à réplica de leitura é feito simplesmente adicionando o parâmetro abaixo à string de conexão:
ApplicationIntent=ReadOnly

Diferente de replicações tradicionais, o Read Scale-out não exige configuração, não possui complexidade operacional, participa automaticamente dos mecanismos de failover e garante que as consultas de leitura sempre enxerguem dados atualizados em tempo real.

Quando ocorre um failover, o comportamento do Read Scale-out é completamente diferente de uma réplica tradicional. Em arquiteturas com replicação clássica (Transactional Replication, Always On configurado manualmente, Azure SQL Replica), a aplicação precisa trocar a string de conexão para apontar para o novo primário. Já no Read Scale-out, o Azure promove automaticamente uma das réplicas para primária e recria a réplica de leitura de forma transparente, mantendo o mesmo endpoint lógico. Isso significa que nenhuma alteração de string de conexão é necessária, e tanto as conexões de escrita quanto as de leitura continuam funcionando normalmente após o failover.

Backups e Retenção (PITR / LTR)

O Azure SQL Database mantém backups automáticos de todos os bancos, incluindo full, differential e transaction log, permitindo restauração a qualquer ponto no tempo (PITR – Point in Time Restore) dentro do período de retenção configurado.

Por padrão, todos os bancos possuem 7 dias de retenção PITR, podendo ser estendido até 35 dias. Esses backups ficam armazenados em storage gerenciado pelo Azure e fazem parte do custo padrão do serviço apenas até o limite de retenção padrão.

Retenção PITR (curto prazo)

• A retenção padrão (7 dias) está incluída no custo do banco.
• Qualquer retenção acima disso (8–35 dias) gera cobrança adicional de storage.
• O valor é calculado com base no tamanho total do banco e no volume de logs gerados.

Em bancos acima de algumas centenas de GB, estender a retenção PITR de 7 para 35 dias pode facilmente adicionar centenas ou milhares de dólares por mês em custo de storage invisível.

Retenção de Longo Prazo (LTR)

O LTR é utilizado para requisitos legais e auditorias, permitindo manter cópias completas do banco por semanas, meses ou anos.

• Você pode configurar retenções semanais, mensais e anuais.
• Os backups LTR são cobrados integralmente como storage de backup.
• O custo cresce linearmente com o tamanho do banco e o número de cópias mantidas.

Diferença de custo por tier e arquitetura

• DTU e vCore General Purpose: Os backups são armazenados em Azure Premium Storage remoto, com custo proporcional ao tamanho total do banco.
• vCore Business Critical: Apesar de os dados ficarem em SSD local, os backups continuam sendo armazenados em storage remoto e seguem o mesmo modelo de cobrança.
• Hyperscale: Possui o maior impacto potencial, pois o banco pode chegar a dezenas de TB e os backups (inclusive PITR e LTR) acompanham esse crescimento, podendo superar facilmente o custo de computação.

Exemplo real de impacto financeiro

Um banco de 2 TB com retenção PITR estendida para 35 dias e LTR configurado para manter 12 backups mensais pode facilmente gerar um custo adicional estimado de backup de USD 600 ~ 1.000/mês no LRS/ZRS e USD 1.200 ~ 2.100/mês no GRS/GZRS, podendo ser ainda maior em bancos Hyperscale acima de 10 TB.

Elastic Pool

O Elastic Pool é um modelo de compartilhamento de recursos do Azure SQL Database onde vários bancos de dados passam a consumir um pool comum de CPU e I/O, mantendo governança individual de memória por banco (buffer pool separado), ao invés de cada banco possuir recursos totalmente dedicados.

No modelo DTU, o Elastic Pool utiliza eDTUs (Elastic DTUs). Apesar da nomenclatura ser equivalente, o modelo de governança do pool faz com que, na prática, sejam necessárias mais eDTUs para entregar a mesma performance de um banco Single Database em DTU.

Como funciona

• O pool possui um total de vCores ou eDTUs compartilhados.
• Cada banco tem limites mínimos e máximos configuráveis.
• O Azure distribui dinamicamente CPU e I/O entre os bancos.
• Bancos ociosos cedem recursos para bancos que estão sendo utilizados.

Limitações e Particularidades do Elastic Pool

• O Elastic Pool possui limite global de armazenamento compartilhado entre todos os bancos.
• Cross-database queries funcionam apenas entre bancos que estão no mesmo pool e servidor lógico (no Single database não tem esse recurso).
• Columnstore só é suportado a partir do tier S3 / 300 eDTU.
• Recursos como In-Memory OLTP e Memory-Optimized Tables não são suportados em Elastic Pools.
• Workloads intensivos de log (WRITELOG) sofrem mais governança que em bancos Single Database.

Quando Elastic Pool faz sentido

• Ambientes multi-tenant com centenas ou milhares de bancos (criando vários pools, pois cada pool suporta até 500 bancos).
• Aplicações SaaS com uso imprevisível por cliente.
• Bancos pequenos que ficam ociosos a maior parte do tempo.
• Cenários onde o custo individual por banco se torna proibitivo.

Quando NÃO usar Elastic Pool

• Bancos com picos simultâneos constantes.
• Workloads sensíveis a latência previsível e WRITELOG.
• Bancos críticos que precisam de performance mínima garantida por banco.

Elastic Pool e vCore

• Existe em DTU e vCore, mas no vCore é onde ele faz mais sentido, pois permite Azure Hybrid Benefit, reservas e arquitetura moderna.
• No vCore, pools existem em General Purpose e Business Critical.
• Hyperscale Pools existem, mas o modelo mais comum e eficiente para SaaS massivo é o General Purpose Pool.

Conclusão

A escolha entre DTU e vCore não é apenas uma questão de preço, mas de estratégia de arquitetura, governança e evolução da plataforma. O modelo DTU é fantástico pela sua simplicidade e baixo atrito operacional, enquanto o vCore entrega a robustez, a previsibilidade e a transparência necessárias para ambientes que já se comportam como infraestrutura crítica, além de facilitar a análise de capacidade e o planejamento financeiro de migrações de ambientes on-premises para o Azure SQL Database.

Se você está começando um projeto novo, pequeno ou com uso ainda imprevisível, o DTU Standard atende muito bem e permite crescer de forma simples. Se precisa de latência mínima de disco, alta taxa de log e consistência de performance, o caminho correto é o vCore Business Critical. Se o seu banco cresce rapidamente ou precisa ultrapassar os limites tradicionais de tamanho, o Hyperscale passa a ser uma decisão arquitetural, não apenas uma escolha de tier.

Para ambientes com uso intermitente, desenvolvimento, homologação e workloads que ficam inativos grande parte do tempo, o vCore Serverless entrega o menor custo possível sem abrir mão de recursos de plataforma. Já para empresas que possuem Software Assurance, o vCore com Azure Hybrid Benefit e reservas representa uma economia estrutural que o modelo DTU simplesmente não consegue oferecer.

Para aplicações SaaS e cenários multi-tenant com dezenas ou centenas de bancos, com picos de uso variados e não concorrentes, o Elastic Pool é a forma mais eficiente de consolidar custo e capacidade, permitindo escalar dezenas de bancos sobre um mesmo conjunto de recursos compartilhados.

Em resumo: DTU é uma excelente porta de entrada. vCore é o caminho natural de maturidade.

Espero que tenham gostado dessa dica, um grande abraço e até a próxima!