Skip to the content

Understanding Azure SQL Database Purchasing Models

Azure SQL Database is a relational database service that runs on the cloud. It is a fully managed PaaS (platform as a service) database engine that handles many of the database management functions for you such as upgrading, patching, backups, and monitoring. At its core, Azure SQL Database runs the latest and most stable version of the SQL Server database engine on a fully-patched operating system. You can use all the features you love (and hate) of SQL Server without the risk of availability because of versioning.

When you purchase an Azure SQL Database, you must choose one of two purchasing models (which you can change and adjust later as your needs change). The selection of a purchasing model is important and has a direct impact on the cost and performance of your database. The purchasing models are vCore and DTU.

Azure SQL Servers to Datacenter


vCore Purchasing Model

When you select the vCore purchasing model you have full control of the compute resources, such as the service tier, number of vCores, amount of memory, and generation of hardware. This model gives you a lot of flexibility such as:

  • Higher compute, memory, I/O, and storage limits.
  • Control over the hardware generation to better match compute and memory requirements of the workload.
  • Pricing discounts for Azure Hybrid Benefit (AHB).
  • Greater transparency in the hardware details that power the compute, facilitates planning for migrations from on-premises deployments.
  • Reserved instance pricing is only available for vCore purchasing model.
  • Higher scaling granularity with multiple compute sizes available.

In terms of compute cost, you must select the provisioned compute tier or the serverless compute tier. In the provisioned compute tier, the compute cost reflects the total compute capacity that is provisioned for the application. In the serverless compute tier, compute resources are auto-scaled based on workload capacity and billed for the amount of compute used, per second.

Regarding storage, you are billed for the provisioned storage based on the maximum database or pool size you select as opposed to only what you use.

This model offers three different service tiers:

  • General Purpose. Fits most business workloads and offers balanced options for compute and storage with a budget in mind. It allows up to 1 replica but no read-scale replicas and zone-redundant high availability. The pricing is based on the number of vCores, reserved storage, and backup storage but IOPS are not charged.
  • Business Critical. For business workloads that need the highest resiliency to failures. This tier uses several isolated replicas and provides the highest I/O performance per database replica. It allows up to 3 replicas + 1 read-scale replica and zone redundant high availability. The pricing is based on the number of vCores, reserved storage, and backup storage but IOPS are again, not charged.
  • Hyperscale. For business workloads with highly scalable storage and read-scale requirements. Offers high resilience to failures by allowing multiple isolated database replicas. It allows zone-redundant high availability. The pricing is based on the number of vCores for each replica and used storage. IOPS are not charged but this could change in the future.

DTU Purchasing Model

The DTU purchasing model is based on a unit of measurement called Database Transaction Unit or DTU. This unit is, as a popular insurance commercial would say, "a bundle" of compute costs where each DTU includes a measure of CPU, memory, reads, and writes. This is a simpler model to work with, but with that simplicity also comes limitations in terms of hardware, compute, memory, and I/O; in the sense that you can only choose a preconfigured bundle that includes compute resources and storage.

This model is ideal for everybody who wants a simple, preconfigured, and mostly fixed monthly price. Compared to the vCore model, the DTU model doesn’t offer a clear view of where the expenses are happening since it is all bundled. All you see are consumed DTUs, which is why it is said that the vCore model is more transparent.

This model allows you to choose between three service tiers:

  • Basic. For small workloads with low compute requirements. It provides 1-4 IOPS per DTU and an approximate latency of 5 ms for reads and 10 ms for writes. This tier doesn’t allow In-Memory OLTP or columnstore indexes. The backup retention is 7 days, and it has a fixed 5 DTU per database limit and a maximum database size of 2 GB.
  • Standard. For workloads with low, medium, or high compute requirements. It provides 1-4 IOPS per DTU and an approximate latency of 5 ms for reads and 10 ms for writes. This tier doesn’t allow In-Memory OLTP and for columnstore indexes you must be using at least an S3 DTU plan which equals 100 DTU. The backup retention is 35 days. The maximum amount of DTUs per database you can request is 3,000 and a maximum database size of 1 TB.
  • Premium. For workloads with low, medium, or high compute requirements. It provides at least 25 IOPS per DTU and an approximate latency of 2 ms for reads and writes. This tier allows In-Memory OLTP and columnstore indexes. The backup retention is 35 days. The maximum amount of DTUs per database you can request is 4,000 and a maximum database size of 4 TB. This is the only tier that supports read scale-out and zone redundant high availability.

Choosing a Purchasing Model: vCore vs DTU 

The following indicators give us the necessary information to choose a purchasing model:

Select the vCore purchasing model if you:

  • Want to have control over hardware resources.
  • Your workload requires high resilience to failures.
  • Your workload requires high I/O performance.
  • Your workload requires highly scalable storage.
  • Must have replicas.
  • You can manage a reasonably unpredictable monthly cost.

Select the DTU purchasing model if:

  • You want to have a predictable, fixed monthly cost.
  • You have no need to control the hardware resources.
  • Your workload does not require high resilience to failures, I/O performance, or scalable storage.

Summary

Azure SQL Database is a fully-managed relational database service that offers two very different purchasing models, vCore and DTU. The vCore model offers great flexibility for computing resources and hardware generation as well as higher limits, scalability, and resilience to failures. The DTU model bundles compute resources into a single, easier-to-manage unit of measure that is billed at a fixed monthly price, however, it doesn’t allow for hardware generation selection or fine-tune the compute resources needed for a workload.

If you want more information about Azure SQL Database development, any other Azure cloud services, or custom enterprise software development, you can count on us!

Schedule a free consultation

As a Gold-certified Microsoft Partner, you can trust us with your business services. You can start by getting in touch to organize a free consultation to see how we can exceed your software and web service needs!

View Services Link        Get in Touch with CSW

Jose R. Guay

About the author

Jose R. Guay

Software Architect

Microsoft Azure, Azure SQL, Azure Managed Services, Azure Cost Management
chatsimple