The vCore pricing model is now the recommended option and allows you to choose the number of virtual CPU cores your database will use. You don’t have any choice over the amount of RAM, but storage is separate from a pricing perspective—that is, you pay for the storage you use on top of the vCore costs.

The vCore pricing also enables an option for hybrid benefit, whereby you can save costs if you have an Enterprise license agreement with Microsoft for SQL Server.

Serverless pricing is similar to the vCore pricing. You choose the number of vCores to assign to your database; however, with serverless, the number of vCores are the minimum and maximum number of cores that will be used. With the serverless pricing model, your databases will automatically scale up and down in response to demand. An Auto-pause option will cause the database to stop using any compute resources if it has been idle for a set period.

This makes servers an excellent choice for development environments or scenarios where ad hoc access is required—for example, for data analytics solutions.

Important note

Because storage is billed separately to compute when your database pauses, with the serverless option you will still incur storage costs.

DTUs combine compute, storage, and input/output (I/O) resources into a single unit. DTU pricing offers much smaller and granular performance tiers; for example, the smallest 5 DTU option costs around 5 US Dollars (USD) a month. The DTU pricing model is ideal for when you want a more straightforward, preconfigured option.

Serverless and DTU-based pricing are not available for Azure SQL Managed Instance.

The final choice when deciding on an Azure SQL offering is the service tier.

SQL service tiers

Azure SQL service tiers represent different levels of performance, scalability, and redundancy for SQL workloads. The different tiers are General Purpose/Standard, Hyperscale, and Business Critical, although this last option is called Premium when you opt for the DTU pricing model. The Hyperscale tier is only supported on Azure SQL Database, while Azure SQL Managed Instance only supports General and Business Critical tiers.

General tier

The General tier is the default model when creating an Azure SQL Database or Azure SQL Managed Instance and is designed for generic workloads or when cost economies are essential.

The General tier offers a 99.99% service-level agreement (SLA) and is resilient against failure within its region. It achieves this by separating the compute nodes and the underlying storage. At any one time, a single compute node runs a sqlservr.exe process with cached and transient data being stored on solid-state drives (SSDs) attached to that node. The database files themselves are held in Azure Blob storage, replicated within a region three times. Secondary compute nodes run on standby. In the event of either a system failure or a maintenance task being performed on the primary node, the process will move over to a standby node.

The following diagram shows this concept:

Figure 12.2 – Azure SQL General service tier redundancy

The General service tier supports up to 80 vCores and 4 terabytes (TB) of storage for Azure SQL Database, and 8 TB storage for Azure SQL Managed Instance. Latency is between 2 and 10 milliseconds (ms), and this is an essential value as for some applications, this variance may not be acceptable.