Continuing with the Azure SQL Database topic, this post focuses on different service tiers available for the Azure SQL Databases with vCore purchasing model. The vCore purchasing model is one of the two purchasing models available for the Azure SQL Database, the other one being DTU. There are three service tiers available for vCore purchasing model: General Purpose (GP), Business Critical (BC) and Hyperscale.
Each of the tiers has their own performance characteristics, defined further by the hardware configuration we pick.
Let’s see how these tiers and hardware configurations compare to each other.
Hardware configurations
Before going to the service tiers, let’s take a quick look at the available hardware configurations. As mentioned before, the selection of hardware configuration also has an impact on the service tier performance and compute resources.
The available hardware configurations for Azure SQL Database and vCore purchasing model are:
| General Purpose | Business Critical | Hyperscale |
|---|---|---|
| Gen 5 | Gen 5 | Gen 5 |
| Fsv2 | M-series | DC-series |
| DC-series | DC-series | Premium-series |
| Premium-series (memory optimized) |
Besides the Serverless options, a topic for another post, each service tier has at least 3 different options for hardware configuration. Let’s start by looking at first the General Purpose tier.
Azure SQL Database: General Purpose
General Purpose tier for Azure SQL database is, as you can probably guess, the budget option that works best with non-demanding workloads. The General Purpose comes with remote premium storage. This means that the latencies and throughput for the storage are not really that great.
The compute and memory characteristics for the General Purpose tier are:
| Hardware | Compute | Memory |
|---|---|---|
| Gen 5 | Min 2 vCores, Max 128 vCores | Min 10.4 GB, Max 625 GB |
| Fsv2 | Min 8 vCores, Max 72 vCores | Min 15.1 GB, Max 136 GB |
| DC | Min 2 vCores, Max 8 vCores | Min 9 GB, Max 36 |
We’ll get about 5 GB of RAM for each vCore with the Gen 5 hardware, and about 2 GB with the Fsv2. If you’re wondering why so little, the Fsv2 is the compute optimized hardware that gives you quite a lot of CPU speed (3.4 to 3.7 GHz), compared to Gen 5 (2.3 GHz).
The storage performance characteristics for the General Purpose tier are:
| Hardware | Storage Latency | IOPS |
|---|---|---|
| Gen 5 | 5 ms – 10 ms | 640 – 16,000 |
| Fsv2 | 5 ms – 10 ms | 2,560 – 12,800 |
| DC | 5 ms – 10 ms | 640 – 2,560 |
The storage on General Purpose isn’t that great. The 5 to 10 ms latency can be an especially painful surprise. However, with 16,000 max IOPS, you shouldn’t put I/O intensive workloads here anyway.
Azure SQL Database: Business Critical
The Business Critical tier for Azure SQL Database takes the performance to another level. This is typically the service tier I’d pick for any serious production workloads, and the one I often end up recommending to my customers when they run into issues with General Purpose.
| Hardware | Compute | Memory |
|---|---|---|
| Gen 5 | Min 2 vCores, Max 128 vCores | Min 10.4 GB, Max 625 GB |
| M-series | Min 8 vCores, Max 128 vCores | Min 235.4 GB, Max 3,767 GB |
| DC | Min 2 vCores, Max 8 vCores | Min 9 GB, Max 36 |
Out of these hardware configurations, the M-series (memory optimized) comes with enough RAM to satisfy most workloads needs.
When it comes to storage, it also provides quite a nice performance, especially when compared to General Purpose:
| Hardware | Storage Latency | IOPS |
|---|---|---|
| Gen 5 | 1 ms – 2 ms | 8,000 – 327,680 |
| M-series | 1 ms – 2 ms | 12,499 – 160,000 |
| DC | 1 ms – 2 ms | 14,000 – 44,800 |
The main reason for the great storage performance is, that with Business Critical tier, we’re using fast, local SSDs.
The final service tier we’re covering in this post is the Hyperscale one. From an architecture perspective, Hyperscale is quite different from the other two, enough so to make a blog post of its own. However, for now, let’s just look at the performance of it.
Azure SQL Database: Hyperscale
The Hyperscale service tier is the most scalable of all the service tiers, being able to handle any type of workload. The hardware options for Hyperscale tier includes the recently added Premium and memory optimized Premium hardware configurations.
| Hardware | Compute | Memory |
|---|---|---|
| Gen 5 | Min 2 vCores, Max 80 vCores | Min 10.4 GB, Max 415.2 GB |
| Premium | Min 2 vCores, Max 128 vCores | Min 10.4 GB, Max 625 GB |
| Premium, memory optimized | Min 2 vCores, Max 80 vCores | Min 20.8 GB, Max 830.5 GB |
| DC | Min 2 vCores, Max 8 vCores | Min 9 GB, Max 36 |
It should be noted that the Premium hardware does provide nice performance benefits over the Gen 5 CPUs. For more details on the differences between Gen 5 and Premium, check this blog post from Microsoft.
From the storage performance perspective, Hyperscale tier also provides us with a pleasant, low latency and high IOPS combination.
| Hardware | Storage Latency | IOPS |
|---|---|---|
| Gen 5 | Local read: 1 ms – 2 ms Local write: 1 ms – 4 ms Remote read: 1 ms – 4 ms | 8,000 – 204,800 |
| Premium | Local read: 1 ms – 2 ms Local write: 1 ms – 4 ms Remote read: 1 ms – 4 ms | 8,000 – 327,680 |
| Premium, memory optimized | Local read: 1 ms – 2 ms Local write: 1 ms – 4 ms Remote read: 1 ms – 4 ms | 10,240 – 327,680 |
| DC | Local read: 1 ms – 2 ms Local write: 1 ms – 4 ms Remote read: 1 ms – 4 ms | 14,000 – 44,800 |
For the Hyperscale, I’ve listed both local and remote latencies. The reason for listing the remote latency is due to the unique architecture of the Hyperscale tier. The compute replicas do not cache the full copy of the database locally, and if it has to retrieve the data from the remote page servers, the latency will be a tad higher.
Between these three tiers, and multiple hardware configurations, it’s difficult to think of a workload that wouldn’t fit into Azure SQL Database, either from a compute or storage performance standpoint.
Wrapping it up
I tend to prefer vCore purchasing model over the DTU model. One of the main reasons for me is, that I know exactly what kind of performance to expect. I will know the compute, memory and storage I have. With the DTU model, that gets a bit muddier.
I also really like the Azure SQL Database as a service, but I find that my customers often have few issues with it, the most common reasons being.
- People try to cut costs and use General Purpose for absolutely everything. Just because it’s named General Purpose, it doesn’t mean that it’s a great fit for most workloads.
- People try to migrate existing database workloads there. Trust me. Azure SQL Database is so much better, when it’s used for greenfield and more cloud native development.
- The final point relates directly to the previous one. Azure SQL Database doesn’t come with a SQL Server Agent. Or a proper instance, you can read my previous post about it, so there’s no way to schedule regular maintenance jobs. While there’s a lot of discussion about whether you need to maintain indexes or not, not doing it, can make your databases bloat. Besides the performance impact database bloat might have, it will have an impact on your storage costs.
Thank you for reading! Hopefully, you found this summary useful. In the next post I’ll look into the details of the DTU purchasing model.
Leave a Reply