Azure SQL Database vs SQL Server on Azure VM: Cost Comparison (2026)

If you are moving a SQL Server workload to Azure, the first big decision is where it will run: Azure SQL Database (a fully managed database service) or SQL Server on an Azure Virtual Machine (your own SQL Server, running on a VM you control). Both work well. But they bill you in very different ways, and picking the wrong one can quietly double your monthly bill.

Azure SQL Database vs SQL Server on Azure VM cost comparison

This guide breaks down what you actually pay for in each option, where the hidden costs are, and a simple way to decide.

Quick answer

  • Choose Azure SQL Database for new applications, single databases, variable or spiky workloads, and teams that do not want to manage patching, backups or high availability.
  • Choose SQL Server on an Azure VM when you need full instance control: SQL Agent jobs across databases, SSIS/SSRS on the same box, OS-level access, specific SQL Server versions, or third-party software installed next to SQL Server.
  • Consider Azure SQL Managed Instance when you want near-full SQL Server compatibility (SQL Agent, cross-database queries) but still want Microsoft to handle patching and backups.

What you pay for: Azure SQL Database

Azure SQL Database is a platform service. Microsoft runs the OS, SQL Server engine, patching, backups and built-in high availability. You pay for:

  • Compute. Either the DTU model (a bundled measure of CPU, memory and I/O, simple for small apps) or the vCore model (you pick cores and memory, and it supports Azure Hybrid Benefit and reserved capacity).
  • Storage. Data size, billed per GB (included up to a limit in DTU tiers).
  • Backup storage. Point-in-time backups are included up to a point. Long retention or geo-redundant backup storage adds cost.

Serverless: pay only while the database is active

The serverless tier bills compute per second while the database is in use, and can auto-pause after an idle period. While paused, you pay only for storage. This is ideal for dev/test databases and apps used mainly during business hours.

Watch out: any open connection keeps the database awake. SSMS left open, application connection pools and health probes can all prevent auto-pause, so a "cheap" serverless database can end up billing all day.

The free offer

Microsoft offers up to 10 free General Purpose serverless databases per subscription. Each one gets 100,000 vCore seconds of compute, 32 GB of data and 32 GB of backup storage every month, for the lifetime of the subscription. That is enough for learning, small side projects and proofs of concept, as long as the database is allowed to pause.

What you pay for: SQL Server on an Azure VM

On a VM, you get a full Windows or Linux server with SQL Server installed. You control everything, and you pay for everything:

  • VM compute. Billed per hour the VM is running, whether SQL Server is busy or idle.
  • SQL Server license. Either included in the VM price (pay-as-you-go images) or brought from your own licenses with Azure Hybrid Benefit. Developer and Express editions have no license cost.
  • Managed disks. OS, data and log disks. Premium SSD or Ultra disks for production performance can be a significant part of the bill.
  • Backups. Azure Backup or backup to Blob storage, plus the storage it uses.
  • High availability. An Always On availability group means at least a second VM, plus its license (unless covered by your license terms) and disks.
  • Your time. Patching, monitoring, backup testing and failover planning are now your team's job.

Side-by-side comparison

Cost factorAzure SQL DatabaseSQL Server on Azure VM
Compute billingPer DTU or vCore; serverless bills per secondPer hour the VM runs
Idle costNear zero on serverless when pausedFull price unless you shut the VM down
SQL licenseIncluded, or reduced with Azure Hybrid BenefitIncluded in VM price, or bring your own
BackupsBuilt in (extra for long retention)You configure and pay for storage
High availabilityBuilt inExtra VMs and licensing
Patching and adminHandled by MicrosoftYour responsibility
Instance-level featuresLimited (no SQL Agent, no cross-database queries)Everything SQL Server supports

Five ways to cut the bill (either option)

  1. Use Azure Hybrid Benefit if your company already owns SQL Server licenses with Software Assurance. It often removes the largest single line item.
  2. Buy reserved capacity (1 or 3 years) for steady production workloads. Pay-as-you-go is the most expensive way to run something 24x7.
  3. Right-size after a month. Most databases are over-provisioned at migration. Check actual CPU, memory and I/O, then scale down.
  4. Use serverless or shut down non-production. Dev and test environments rarely need to run nights and weekends.
  5. Fix the queries first. A missing index can force you into a tier two sizes larger than needed. Tuning is often the cheapest "upgrade".

A simple decision checklist

  • Does the app need SQL Agent, cross-database queries or CLR? → Managed Instance or VM.
  • Do you need OS access or software installed on the server? → VM.
  • Is it one database with variable load? → Azure SQL Database, likely serverless.
  • Is it many small databases with uneven load? → Azure SQL Database elastic pool.
  • Do you own SQL licenses with Software Assurance? → Factor in Azure Hybrid Benefit for every option.

Practical tip: measure before you migrate

Before choosing a tier, capture at least two weeks of real usage from your current server: average and peak CPU, memory, IOPS and log write throughput. Many teams size Azure based on the old server's hardware, not its actual load, and end up paying for capacity they never use. Start one size smaller than you think, monitor for a week after go-live, and scale up only if the numbers say so. Scaling Azure SQL Database up or down takes minutes.

Final thoughts

Azure SQL Database usually wins on total cost for new and modern applications, because you stop paying for idle servers and admin work. SQL Server on a VM wins when you genuinely need full control or legacy features. Before you decide, price both options with the Azure Pricing Calculator using your real workload numbers, since prices vary by region and change over time.

Next in this series: How to reduce Azure SQL costs, a practical checklist.

Related reading:

Comments

Post a Comment

Popular posts from this blog

SARGable Queries in SQL Server: Why Functions in WHERE Slow You Down

Image
You add the perfect index, run the query, and SQL Server still scans the whole table. One of the most common reasons is a non-SARGable predicate: a WHERE clause written in a way that stops SQL Server from using the index to seek. The fix is usually a small rewrite. What SARGable means SARGable stands for S earch ARG ument- able . A predicate is SARGable when SQL Server can use it to jump straight to the matching rows in an index (an index seek). If you wrap the indexed column in a function or calculation, SQL Server can no longer search the index for a value; it has to calculate the expression for every row, which means a scan. The rule of thumb: leave the column bare on one side of the comparison , and do any calculation on the other side. Common non-SARGable patterns and their fixes Functions on date columns -- Not SARGable: YEAR() runs on every row WHERE YEAR(OrderDate) = 2026 -- SARGable: a range on the bare column WHERE OrderDate >= '2026-01-01' AND OrderDate < ...
Read more

How to Read a SQL Server Execution Plan (Beginner's Guide)

Image
When a query is slow, the execution plan tells you exactly what SQL Server did to run it: which indexes it used, how it joined tables and where the time went. Plans can look intimidating, but you only need a few habits to find the problem in most of them. Estimated vs actual plans SQL Server Management Studio (SSMS) can show two kinds of plan: Estimated plan (Ctrl+L): what SQL Server plans to do, without running the query. Useful for queries that are too slow or too risky to run. Actual plan (Ctrl+M, then run the query): the same plan plus what really happened, including actual row counts and warnings. Use this whenever you can. Turn on IO and time statistics at the same time so you have numbers to compare after each change: SET STATISTICS IO, TIME ON; -- run the query with "Include Actual Execution Plan" enabled SET STATISTICS IO, TIME OFF; Read from right to left Data flows from right to left. The operators on the far right read data from tables and indexes; each operato...
Read more