Azure SQL Pricing: DTU vs vCore Models

Azure SQL Database offers two purchasing models for compute and storage resources: the DTU-based model and the vCore-based model. The DTU model is a legacy, bundled approach where compute, storage, and I/O are combined into a single unit called the Database Transaction Unit (DTU). The vCore model is a newer, more flexible model that allows you to independently scale compute (vCores), memory, and storage, and offers additional features like Azure Hybrid Benefit, reserved instances, and serverless compute.

The DTU model was designed for simplicity. Microsoft pre-configured tiers (Basic, Standard, Premium) with fixed ratios of CPU, memory, and I/O. This works well for small to medium workloads where performance requirements are predictable and you don't need fine-grained control. The vCore model was introduced to meet the demands of enterprise workloads that require predictable performance, high scalability, and cost optimization through reserved capacity or hybrid licensing.

A DTU is a blended measure of CPU, memory, and I/O (data I/O and log I/O). Each service tier (Basic, Standard, Premium) has predefined DTU limits. For example, Standard S2 provides 50 DTUs. The database engine monitors resource consumption continuously. If the cumulative resource usage exceeds the DTU limit, queries may be throttled or queued. The DTU calculation is proprietary, but Microsoft publishes benchmarks: 1 DTU roughly equals 1 logical CPU + 2 GB memory + a certain I/O throughput (specific per tier). The DTU model does not expose individual resource metrics easily; you see a single DTU percentage in Azure Monitor.

In the vCore model, you choose the number of virtual cores (vCores) and the hardware generation (Gen5, Fsv2, M-series). Each vCore corresponds to a logical CPU thread. Memory is allocated proportionally: Gen5 offers 5.1 GB per vCore. You also select the max data size (up to 4 TB for General Purpose, 100 TB for Hyperscale). I/O throughput is determined by the storage type and configuration. You can choose between provisioned throughput (fixed vCores) or serverless (auto-scaling compute based on workload, billed per second). The vCore model also supports Azure Hybrid Benefit (use your own SQL Server license to reduce cost) and Reserved Instances (prepay for 1 or 3 years for up to 72% discount).

To create a DTU database using Azure CLI:

az sql db create --resource-group myGroup --server myServer --name myDB --service-objective S2

To create a vCore database:

az sql db create --resource-group myGroup --server myServer --name myDB --service-objective GP_Gen5_2

To check the current pricing model:

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS Edition,
       DATABASEPROPERTYEX(DB_NAME(), 'ServiceObjective') AS ServiceObjective;

The edition will be 'Basic', 'Standard', 'Premium' (DTU) or 'GeneralPurpose', 'BusinessCritical', 'Hyperscale' (vCore).

A large e-commerce company runs its product catalog and order processing on Azure SQL Database. During Black Friday, traffic surges 10x. They need to scale compute quickly without over-provisioning during off-peak months. They chose the vCore serverless model for the General Purpose tier. During normal days, the database auto-scales down to 2 vCores and even pauses after 1 hour of inactivity at night. During the sale, it scales up to 16 vCores automatically. They set a minimum of 2 vCores to avoid cold starts. The billing is per-second for compute, saving ~60% compared to provisioned. The key configuration is setting the auto-pause delay to 60 minutes and max vCores to 16. They also use Azure Hybrid Benefit with existing SQL Server licenses to reduce costs further. Misconfiguration: Initially they set the auto-pause delay too short (10 minutes), causing frequent pauses during light traffic, leading to user latency on reconnections. They increased it to 60 minutes.

A bank requires high-performance transaction processing with low latency and high availability for its core banking system. They need local SSD storage for fast I/O and synchronous replication for zero data loss. They chose the vCore Business Critical tier with 8 vCores on Gen5 hardware. The database is 2 TB. They use read-scale replicas (one secondary) to offload reporting queries. They also use zone-redundant configuration for resilience. Cost is higher but justified by SLAs. They monitor vCore usage and I/O latency. Common problem: Inadequate storage throughput – Business Critical provides up to 128 MB/s per vCore, but if the application writes large logs, they needed to increase vCores to get more I/O bandwidth. They learned that I/O limits are tied to vCores.

A SaaS startup runs 50 small customer databases, each under 5 GB, with low activity. They want to minimize cost and management overhead. They chose the DTU model with an elastic pool (Standard tier). They created a pool of 200 DTUs shared across all databases. Each database gets up to 50 DTUs, but idle databases consume no DTU. This is simpler than managing 50 separate vCore databases. Cost: $200/month for the pool vs $500/month if each were a vCore database with 1 vCore. The drawback: if one database spikes, it can throttle others. They set a max DTU per database to 10 to prevent noise. The exam scenario often asks: 'Which model for many small databases with variable activity?' Answer: DTU elastic pool.