Azure Database Cost Optimization: SQL, MySQL & PostgreSQL

Azure database costs get complicated quickly because there isn’t one pricing model to optimize. Azure SQL Database, Managed Instance, Elastic Pools, MySQL, and PostgreSQL each behave differently — with different compute models, scaling options, HA costs, and commitment discounts.

That means the biggest savings usually come from making the right decision at each layer: choosing the right database service and deployment model, right-sizing compute and storage, eliminating unnecessary HA or replica capacity, and then applying the right commitment once usage is predictable.

This guide breaks down where costs concentrate across Azure’s major database services and how to reduce them without locking too much spend into the wrong engine or configuration. For the broader framework, see the main Azure cost optimization guide.

Azure SQL: Database, Managed Instance & Elastic Pools

These aren't three equivalent products. Azure SQL Database and Managed Instance both run on the SQL Server engine but price differently: Azure SQL Database supports either DTU- or vCore-based purchasing, while Managed Instance is priced on vCores only. Elastic Pools aren't a separate product at all — they're a deployment option of Azure SQL Database itself, sharing a pool of DTUs (or vCores) across multiple databases instead of provisioning each one individually. Here's how they differ in practice:

Managed Instance is the most expensive default of the three, since it bills for a full always-on instance regardless of how much SQL Server compatibility a given workload actually uses — it's worth the cost only when that compatibility is a real requirement, not a convenience. Elastic Pools save the most when databases genuinely don't peak at the same time; pooling databases that do peak together just adds the pool's per-unit premium without the offsetting benefit.

Open-Source Databases — MySQL & PostgreSQL

MySQL and PostgreSQL price similarly to each other on Azure — both bill compute, storage, IOPS, and HA separately — but neither shares pricing or right-sizing logic with the SQL family, so a team optimizing Azure SQL Database well can still be significantly overspending on a PostgreSQL Flexible Server running alongside it.

Azure Cosmos DB

Cosmos DB prices differently from the rest of this list — throughput and storage, not instance size, drive the bill.

Storage bills separately, with analytical storage priced below transactional. Multi-region writes multiply RU costs per region. Where teams overspend: autoscale ceilings set well above actual peak, standard throughput on spiky workloads that would fit serverless, and multi-region writes enabled without a real latency or DR need.

Reducing Azure SQL Costs

Beyond choosing the right service, a handful of concrete levers close most of the gap between a working config and an optimized one:

• Serverless vs. provisioned compute — For databases with genuine idle periods (dev/test, low-traffic apps), serverless auto-pauses compute after a configurable idle window and resumes on the next connection, billing only for active use. Provisioned compute makes sense once traffic is steady enough that pause/resume latency becomes a liability.
• DTU vs. vCore selection — DTU bundles compute, storage, and I/O into one tier, which is simpler to size for smaller, less demanding databases. vCore separates compute from storage so each can scale independently — worth it once storage needs outgrow what a DTU tier's bundled allotment covers.
• Right-sizing compute — Query Performance Insight and DTU/vCore utilization metrics over a trailing period, not a single peak day, show where a tier is oversized. Downsizing consistently underutilized tiers is usually the single largest lever here.
• Backup and storage retention — Point-in-time restore retention beyond the included window bills per GB per month. Trimming retention to what's actually required, and offloading long-term retention to cheaper storage where compliance allows, removes a cost that compounds quietly.
• Azure Hybrid Benefit — If you already hold SQL Server licenses with active Software Assurance, Hybrid Benefit swaps the license portion of the compute rate for those existing licenses — a direct discount with no workload changes required.
• Zone redundancy and read replicas — Both add cost for availability and read scaling. Worth confirming the workload's actual SLA and read-traffic patterns justify the premium before applying it uniformly across every tier.

Watch the Costs Outside Compute

Compute tier is one line on the bill. Storage, IOPS, backups, HA, replicas, and cross-region replication are billed independently and don't scale down just because the instance did. Before committing spend to any one engine, check:

• Storage and IOPS sized to actual usage, not provisioned headroom
• HA and replica configurations matched to the workload's actual criticality
• Backup retention set to what's required, not left at defaults
• Cross-region replication tied to a real latency or DR requirement

Committing to Database Spend

Once usage is stable, database spend can be committed at a discount a few different ways: Reserved Capacity covers SQL Database, Cosmos DB, and Storage as a resource-based commitment, MySQL and PostgreSQL Flexible Server each have their own separate 1- and 3-year reserved pricing, and the newer database savings plans offer a spend-based alternative that spans SQL Database, Managed Instance, PostgreSQL, MySQL, and Cosmos DB under a single hourly commitment. See the full guide to Azure commitment management for how these compare to Reservations and Hybrid Benefit across the rest of the environment.

Balancing Reserved Capacity, Database Savings Plans, and right-sizing across five different database services — each with its own pricing model and renewal schedule — is exactly the kind of ongoing, cross-cutting problem that's easy to get wrong by hand as an environment grows.

Managing Azure Database Costs with nOps

nOps was built to handle exactly this balancing act automatically, with:

• Commitment Management: Automatically maximize discounts and minimize commitment risk across Reservations, Savings Plans, Reserved Capacity, and Hybrid Benefit — continuously rebalancing as usage shifts rather than requiring a one-time decision. Customers typically save ~20% by switching to nOps — and with results-based pricing, you pay only when you get better results.
• Unified visibility: Get all of your spending from Azure, AWS, GCP, AI, and SaaS in one place, with cost allocation by application, customer, team, or business unit to understand what is driving spend and where optimization will have the greatest impact.

We've talked to companies that can save millions on their cloud bills by switching to nOps from competitors. Book a free savings analysis to quantify exactly how much more you could save across your Azure databases and the rest of your cloud environment.

nOps manages $5B+ in cloud spend and was recently rated #1 in G2's Cloud Cost Management category.

Demo

AI-Powered Cost Management Platform

Discover how much you can save in just 10 minutes!

Book a Demo

FAQ