Savings Plan for Databases Chegou, mas Será Que Você Deveria Trocar Suas Reservations?
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:
- Acesse Reservations no portal Azure
- Selecione a reserva que quer trocar
- Clique em Exchange
- Configure a nova reserva
- 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:
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
- Anúncio oficial: Savings Plan for Databases — Post original da Microsoft no FinOps Blog anunciando o novo modelo
- Como comprar Azure Savings Plans — Documentação oficial sobre como adquirir um Savings Plan
- Visão geral dos Azure Savings Plans — Como Savings Plans funcionam e quais serviços cobrem
Reservations
- O que são Azure Reservations — Visão geral de como funcionam as reservas no Azure
- Reserved capacity para Azure SQL Database — Detalhes sobre o que a reserva cobre no SQL Database
- Trocas e reembolsos de Azure Reservations — Como fazer exchange de reservas existentes
Pricing e Cost Management
- Azure SQL Database pricing — Calculadora oficial de preços
- Azure Cost Management — Ferramenta pra análise de gastos e recomendações de economia
- Azure Advisor — Recomendações de custo — Recomendações personalizadas de economia baseadas no seu uso