Savings Plan for Databases Chegou, mas Será Que Você Deveria Trocar Suas Reservations?

Savings Plan for Databases Chegou, mas Será Que Você Deveria Trocar Suas Reservations?

17 de junho de 2026

Olá pessoALL,

Se você acompanha novidades do Azure, provavelmente já viu o anúncio: a Microsoft lançou o Savings Plan for Databases. Um modelo de desconto baseado em compromisso de gasto por hora, flexível entre serviços e regiões, com até 35% de economia comparado ao Pay As You Go. Na primeira leitura, parece o tipo de coisa que resolve todos os problemas de quem compra Reserved Instances e fica preso a um SKU, uma região, um serviço específico.

Confesso que minha primeira reação foi exatamente essa. Li o anúncio, olhei os serviços cobertos, vi a palavra "flexibilidade" umas dez vezes e pensei: "Pronto, agora faz sentido migrar tudo pra Savings Plan." Cheguei a abrir o portal pra ver as recomendações no Azure Advisor.

Mas antes de sair trocando, resolvi fazer o que faço com todo cliente: sentar e comparar os números. E o que encontrei mudou minha opinião. Deixa eu te mostrar.

O Que é o Savings Plan for Databases?

Antes de entrar na comparação, vale entender o que é essa novidade.

O Savings Plan for Databases é um modelo de desconto baseado em compromisso de gasto. Você se compromete a gastar um valor fixo por hora (por exemplo, $5/hora) durante 1 ano. Em troca, recebe preços reduzidos em serviços de banco de dados elegíveis. Diferente de uma Reserved Instance, você não se compromete com um serviço específico, uma região ou uma configuração. O Azure aplica o desconto automaticamente a cada hora, priorizando o uso que gera a maior economia primeiro.

Os serviços cobertos incluem:

  • Azure SQL Database
  • Azure Database for PostgreSQL
  • Azure Database for MySQL
  • Azure Cosmos DB
  • SQL Server on Azure Virtual Machines
  • SQL Server enabled by Azure Arc

Qualquer uso além do compromisso por hora continua sendo cobrado pelo preço normal de Pay As You Go. Simples.

Os benefícios anunciados são reais: você ganha flexibilidade pra mover workloads entre serviços e regiões sem precisar recomprar ou reconfigurar compromissos. Se hoje você roda Azure SQL Database e amanhã migra pra PostgreSQL, o desconto acompanha. Se expande pra outra região, o desconto acompanha também. E o orçamento fica previsível — um valor fixo por hora em vez de variação mês a mês.

Pra quem está modernizando ambiente, migrando entre serviços ou expandindo pra múltiplas regiões, isso soa como a solução perfeita.

Mas vamos olhar os números.

A Flexibilidade Tem Um Preço — Literalmente

O Savings Plan for Databases oferece até 35% de desconto em relação ao Pay As You Go. Esse número vem direto do anúncio oficial da Microsoft, com o asterisco de que os 35% são baseados no melhor cenário (Azure SQL Database Serverless, 1 ano).

Agora compara com Reserved Instances:

Modelo de Desconto Compromisso Desconto Típico
Savings Plan for Databases 1 ano, gasto por hora Até 35%
Reserved Instance 1 ano, recurso específico ~40%
Reserved Instance 3 anos, recurso específico ~55-65%

Você leu certo. Reserved Instance de 1 ano já dá mais desconto do que o Savings Plan. E na reserva de 3 anos, a diferença pode chegar a quase o dobro.

"Tá, mas o Savings Plan é mais flexível." Concordo. Flexibilidade é ótimo. Mas flexibilidade tem um preço — literalmente. E a pergunta que importa é: você precisa dessa flexibilidade?

A Pergunta Que Ninguém Faz

Pensa comigo. Quantos dos seus clientes — ou quantos cenários seus — usam múltiplos serviços de banco de dados espalhados por várias regiões e com planos de migrar nos próximos 12 meses?

Eu vou te dizer o que vejo na prática, conversando com clientes toda semana: a maioria roda Azure SQL Database, em uma região, com um workload que não muda de serviço a cada trimestre. Tem o banco de produção, talvez um de staging, e pronto. Não estão migrando pra PostgreSQL mês que vem. Não estão expandindo pra três continentes. O workload é estável, previsível, e vai continuar no mesmo serviço e na mesma região pelos próximos anos.

Pra esse perfil — que é a maioria — Savings Plan significa pagar mais por uma flexibilidade que nunca vai ser usada.

(Aqui entra um GRANDE MAS) — a diferença percentual parece pequena no papel. 35% contra 40%, grande coisa, né? Mas aplica isso ao longo de 3 anos num Azure SQL Database Business Critical com alguns vCores e veja o que acontece.

Vamos a um exemplo pra tangibilizar. Imagina um Azure SQL Database, General Purpose, Gen 5, 8 vCores, rodando numa única região:

Cenário Desconto Estimado Custo Relativo (vs PAYG)
Pay As You Go 0% 100%
Savings Plan 1 ano ~30% ~70%
Reservation 1 ano ~40% ~60%
Reservation 3 anos ~60% ~40%

Se o custo de compute PAYG for, digamos, $1.000/mês, em 3 anos você pagaria:

  • PAYG: $36.000
  • Savings Plan (1 ano, renovando): ~$25.200
  • Reservation 1 ano (renovando): ~$21.600
  • Reservation 3 anos: ~$14.400

A diferença entre Savings Plan e Reservation de 3 anos? $10.800 em 3 anos. Em um workload que não mudou de serviço, não mudou de região, não precisou de nenhuma flexibilidade.

Dez mil e oitocentos dólares. Pra quê? Pra ter a opção de mover pra PostgreSQL — opção que nunca vai ser exercida.

Quando o Savings Plan Faz Sentido De Verdade

Agora, seria desonesto da minha parte pintar o Savings Plan como uma opção ruim. Não é. Pra alguns cenários, faz todo sentido.

Imagina uma equipe que roda uma aplicação global usando Azure SQL Database e Azure Database for PostgreSQL hoje, com planos de expandir pra novas regiões no próximo ano. Esse é o exemplo que a própria Microsoft dá no anúncio, e é legítimo. Em vez de comprar reservas individuais amarradas a serviços e regiões específicas, a equipe compra um Savings Plan com compromisso de $5/hora. Conforme o uso muda entre serviços e regiões, o Azure aplica o desconto automaticamente.

Cenários onde o Savings Plan brilha:

  • Multi-região: Você tem bancos de dados espalhados por East US, West Europe, Southeast Asia — e a distribuição muda conforme o negócio cresce
  • Multi-serviço: Seu ambiente usa SQL Database, PostgreSQL e Cosmos DB, e a proporção de uso entre eles não é estável
  • Modernização ativa: Você está migrando de SQL Server on VMs pra Azure SQL Database, ou de MySQL pra PostgreSQL, e não sabe exatamente quando cada migração vai terminar
  • Startups em crescimento rápido: O workload de hoje não vai parecer nada com o de daqui a 6 meses

Se você se encaixa nesses cenários, Savings Plan pode ser a escolha certa. A flexibilidade justifica o desconto menor porque você realmente vai exercê-la.

Mas se você roda num datacenter só, com um serviço de banco de dados previsível — Reservation ainda é rei.

"Mas Reservation Tem Lock-In" — Será?

Uma objeção que eu ouço muito: "Reservation me prende a um SKU e uma região. E se eu precisar mudar?"

É uma preocupação válida. Mas quem acompanha nosso conteúdo sabe que essa história é mais nuançada do que parece. O Azure permite fazer exchange de reservas. Você pode trocar sua Reserved Instance por outra de tier, região ou SKU diferente sem penalidade de cancelamento. O valor restante é creditado e aplicado na nova reserva.

Na prática:

  1. Acesse Reservations no portal Azure
  2. Selecione a reserva que quer trocar
  3. Clique em Exchange
  4. Configure a nova reserva
  5. Confirme

O crédito proporcional do tempo restante é recalculado automaticamente. Então o "lock-in" da Reservation não é tão rígido quanto parece. Claro, tem limitações — nem toda combinação de SKU permite exchange, e você precisa validar a elegibilidade no portal. Mas a ideia de que você fica preso por 3 anos sem saída não corresponde à realidade.

Reservation Exchange é o tipo de coisa que pouca gente sabe que existe. E faz toda a diferença na hora de decidir entre os dois modelos.

A Estratégia Madura — Combinar os Dois

Agora que entendemos quando cada modelo faz sentido, vou te mostrar o que eu recomendo pra quem quer extrair o máximo de economia.

Use os dois.

Não é brincadeira. A estratégia de FinOps mais eficiente pra bancos de dados no Azure combina Reservations pra carga base e Savings Plan pra variação.

Como funciona na prática:

  1. Identifique sua carga base — Aquele Azure SQL Database que roda 24/7, na mesma região, no mesmo tier, há meses. Esse workload é previsível. Compre uma Reservation de 3 anos e capture o desconto máximo.

  2. Identifique uso variável — Bancos de desenvolvimento que sobem e descem, ambientes de staging temporários, aquele Cosmos DB que é usado por picos de um projeto específico. Pra esse uso, um Savings Plan com compromisso por hora dá desconto sem amarrar a um recurso.

  3. Qualquer coisa além dos dois compromissos — Fica no Pay As You Go. E tudo bem. Nem todo uso justifica compromisso antecipado.

Essa abordagem em camadas garante que o workload estável — que normalmente representa 70-80% do custo — recebe o desconto mais agressivo. E o uso variável também recebe algum desconto, em vez de ficar 100% no PAYG.

É mais trabalho do que simplesmente comprar um Savings Plan genérico? É. Mas o retorno financeiro justifica, especialmente em ambientes maiores.

O Que Muda Pra Quem Já Tem Reservations

Se você já comprou Reserved Instances pro seu ambiente de banco de dados, a chegada do Savings Plan for Databases não muda nada no que você já contratou. Suas reservas continuam valendo, continuam gerando desconto, e se a utilização está em 100%, está tudo certo.

O Savings Plan é uma opção adicional. Não é um substituto. Na próxima renovação, aí sim, revise se faz sentido manter Reservation, migrar pra Savings Plan, ou combinar os dois.

E aqui vai uma dica que vale repetir: quando for analisar, olhe o que você realmente usa. Não o que pode usar um dia. Não a flexibilidade teórica. Olhe os últimos 6 meses de consumo no Cost Management, identifique o que é estável e o que varia, e decida com base nisso.

Lições Aprendidas

  1. Desconto maior não é sinônimo de melhor — Savings Plan oferece até 35%, Reservation oferece 40-65%. O melhor modelo depende do seu cenário, não do desconto máximo possível.

  2. Flexibilidade tem custo — Savings Plan cobra um prêmio de flexibilidade que só faz sentido se você realmente vai mudar de serviço, região ou arquitetura no período do compromisso.

  3. Single region + workload estável = Reservation — Se você roda um banco de dados previsível numa única região (e isso é a maioria dos casos), Reservation de 3 anos continua sendo a opção mais econômica.

  4. Reservation não é lock-in total — Exchange de reservas existe, funciona, e resolve a maioria dos cenários de mudança. Não deixe o medo de "ficar preso" te empurrar pra um modelo mais caro.

  5. A estratégia ideal combina os dois — Reservation pra carga base, Savings Plan pra uso variável, PAYG pro resto. Três camadas, desconto máximo.

  6. Analise antes de comprar — Abra o Cost Management, olhe seus últimos 6 meses, identifique o que é estável e o que varia. A decisão sai dos dados, não do hype do anúncio.

Conclusão

O Savings Plan for Databases é uma adição positiva ao arsenal de FinOps do Azure. Pra quem opera em múltiplas regiões, usa vários serviços de banco de dados e está em processo de modernização, é uma opção que resolve problemas reais.

Mas pra maioria dos cenários que vejo no dia a dia — um Azure SQL Database, uma região, workload estável — Reservation continua oferecendo mais economia. Ponto.

Não se deixe levar pelo hype de "flexibilidade" sem antes abrir sua fatura e entender o que você realmente precisa. Às vezes, a melhor flexibilidade é ter mais dinheiro no caixa.

Se você quer ajuda pra revisar seu ambiente e decidir entre Savings Plan, Reservation, ou uma combinação dos dois, a equipe da AzureBrasil.cloud está sempre disponível. É o que fazemos todo dia.

[]s e até a próxima


Referências

Savings Plan for Databases

Reservations

Pricing e Cost Management

Confira mais:

Fique por dentro das novidades

Assine nossa newsletter e receba as últimas atualizações e artigos diretamente em seu email.

Assinar gratuitamente