Azure SQL Database: vCore Service Tiers

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.

Azure SQL Database
Azure database

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 PurposeBusiness CriticalHyperscale
Gen 5Gen 5Gen 5
Premium-series (memory optimized)
Hardware generations available for each tier, source: https://learn.microsoft.com

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:

Gen 5Min 2 vCores, Max 128 vCoresMin 10.4 GB, Max 625 GB
Fsv2Min 8 vCores, Max 72 vCoresMin 15.1 GB, Max 136 GB
DCMin 2 vCores, Max 8 vCoresMin 9 GB, Max 36
Compute and memory for General Purpose

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:

HardwareStorage LatencyIOPS
Gen 55 ms – 10 ms640 – 16,000
Fsv25 ms – 10 ms2,560 – 12,800
DC5 ms – 10 ms640 – 2,560
Storage for General Purpose

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.

Gen 5Min 2 vCores, Max 128 vCoresMin 10.4 GB, Max 625 GB
M-seriesMin 8 vCores, Max 128 vCoresMin 235.4 GB, Max 3,767 GB
DCMin 2 vCores, Max 8 vCoresMin 9 GB, Max 36
Compute and memory for Business Critical

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:

HardwareStorage LatencyIOPS
Gen 51 ms – 2 ms8,000 – 327,680
M-series1 ms – 2 ms12,499 – 160,000
DC1 ms – 2 ms14,000 – 44,800
Storage for Business Critical

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.

Gen 5Min 2 vCores, Max 80 vCoresMin 10.4 GB, Max 415.2 GB
PremiumMin 2 vCores, Max 128 vCoresMin 10.4 GB, Max 625 GB
Premium, memory optimizedMin 2 vCores, Max 80 vCoresMin 20.8 GB, Max 830.5 GB
DCMin 2 vCores, Max 8 vCoresMin 9 GB, Max 36
Compute and memory for Hyperscale

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.

HardwareStorage LatencyIOPS
Gen 5Local read: 1 ms – 2 ms
Local write: 1 ms – 4 ms
Remote read: 1 ms – 4 ms
8,000 – 204,800
PremiumLocal read: 1 ms – 2 ms
Local write: 1 ms – 4 ms
Remote read: 1 ms – 4 ms
8,000 – 327,680
Premium, memory optimizedLocal read: 1 ms – 2 ms
Local write: 1 ms – 4 ms
Remote read: 1 ms – 4 ms
10,240 – 327,680
DCLocal read: 1 ms – 2 ms
Local write: 1 ms – 4 ms
Remote read: 1 ms – 4 ms
14,000 – 44,800
Storage for Hyperscale

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.

  1. 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.
  2. 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.
  3. 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.

Published by

One response to “Azure SQL Database: vCore Service Tiers”

  1. […] continue with the Azure SQL Database, and the topic of my previous post. This time we’ll look at the Service Tiers for Azure SQL Database when going with the DTU […]

Leave a Reply

%d bloggers like this: