Azure SQL Database DTU vs vCore: Which Purchasing Model Should You Choose?

When you create an Azure SQL Database, one of the first choices is the purchasing model: DTU or vCore. It decides how you size the database, which features you can use and how you can save money. Here is a practical way to choose, and how to move between them later.

Azure SQL Database DTU vs vCore purchasing models

The DTU model

A DTU (Database Transaction Unit) is a bundled measure of CPU, memory, data I/O and log I/O. You pick a tier and a size, such as Standard S3 or Premium P2, and get a fixed amount of all of them together.

  • Basic: tiny databases and development.
  • Standard: typical small to medium workloads.
  • Premium: higher I/O performance and in-memory features.

It is simple: one number to scale, one predictable price, and a set amount of storage included.

The vCore model

In the vCore model you choose the number of virtual cores (with memory tied to the hardware generation) and storage separately, in one of three service tiers:

  • General Purpose: balanced, budget-friendly; remote storage. Also offers the serverless compute option that auto-scales and can auto-pause.
  • Business Critical: local SSD storage, lower latency, built-in readable secondary replica; for demanding OLTP.
  • Hyperscale: very large databases with fast scaling and fast backups and restores.

Feature differences that matter

DTUvCore
SizingBundled unitsCores, memory and storage chosen separately
Azure Hybrid BenefitNoYes (provisioned compute)
Reserved capacity discountsNoYes
Serverless optionNoYes
HyperscaleNoYes
Best forSmall, simple, predictableGrowing, larger or cost-optimised workloads

Choose DTU when

  • The database is small and you want the simplest possible setup.
  • You have no existing SQL Server licences to bring.
  • The workload is steady and you do not need serverless or Hyperscale.

Choose vCore when

  • You own SQL Server licences with Software Assurance: Azure Hybrid Benefit can cut the cost substantially.
  • The workload runs 24x7 and you can commit to reserved capacity.
  • Usage is intermittent (dev/test, business-hours apps) and serverless fits.
  • You need to scale CPU and storage independently, or need Business Critical or Hyperscale.
  • You want sizing that maps clearly to on-premises servers (cores and memory).

Translating DTUs to vCores

Microsoft's rough rule of thumb: about 100 DTUs in Standard ≈ 1 vCore in General Purpose, and about 125 DTUs in Premium ≈ 1 vCore in Business Critical. Treat this as a starting point only; check real CPU and I/O usage after moving and adjust.

Switching models

You can change between DTU and vCore models with a scale operation in the portal, CLI or T-SQL. It is an online operation; connections drop briefly at the end, so do it in a quiet period and make sure your application retries transient errors.

ALTER DATABASE [Payroll]
MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2');

Bottom line

Start with DTU if you want simplicity for a small database. Move to vCore as soon as licensing discounts, reservations, serverless or independent scaling would save money or solve a problem. Prices and available hardware change, so compare options for your region in the Azure Pricing Calculator before deciding.

Related reading:

Comments

Post a Comment

Popular posts from this blog

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

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

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

Image
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. 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 compat...
Read more