Configuring resources for Azure SQL platform-as-a-service

Azure PASS SQL
Purchasing Model and Service Tier

Configuring resources for PASS services involves two different performance-related aspects

• The purchasing model.
• The service tier

The purchasing model: 

It is where we configure direct allocation of CPU, memory, storage space, and possible storage IO operations per second to the Azure SQL offering that we are configuring.

The service tier: 

This defines the maximum amount of resources that could be allocated to our database, the type of storage used for our data, as well as the high availability methodology Azure SQL will use behind the scenes to keep our databases or instances up and running.

The performance sources available to our Azure SQL solution are governed by the specific purchasing model and service tier that we have chosen to use.

We only have 2 purchasing models,

• DTU: Measuring resource allocation by database transaction unit,or DTU
• vCores: Allocating by virtual CPU cores

 For service tier, our options are:

• Basic
• Standard
• General Purpose,
• Premium
• Business Critical
• Hyperscale.

Note: The underlying infrastructure for Standard and General Purpose, and Premium and Business Critical, respectively, are practically identical, which is why they are group

When provisioning Azure SQL platform-as-a-service resources, the actual service tiers that we will be able to choose from will depend on the purchasing model that we have selected.

• DTU model: Basic, Standard or Premium service tiers.
• vCore purchasing model: General Purpose, Business Critical, and the Hyperscale service tiers.

The settings for both purchasing model and service tier can be easily reconfigured, often with only a very brief interruption of service. You can even decide to change to a different purchasing model or service tier entirely, though changing service tiers might take a little longer, as the data will most likely need to be transferred to a different type of storage.

Note: Databases using the Hyperscale tier cannot ever be changed to a different service tier.

Elastic pools: 

• Resource configuration is performed at the pool level, not at the level of any member databases.
• These pool-level resources are then allocated to the member databases as needed, automatically by the Azure SQL service.
• Minimum and maximum resource levels can be configured for member databases collectively, not individually.
• Nor can all of the collective pool members ever use more resources than have been configured for the entire pool.
• elastic pools will automatically allocate resources to their member databases as needed, but are only able to do so within their configured limits.