What is vCore Purchasing Model in Azure

 

Deeper Look At The vCore Purchasing Model

vCore purchasing model

• The vCore purchasing model allows you to select the number of virtual CPU cores that will be available to your Azure SQL solution.
• this is the purchasing model that Azure recommends for most workloads.
• The vCore purchasing model allows separate configuration of compute and storage I/O. Memory.,
• It is allocated in fixed amounts for each vCore in use.
• The vCore purchasing model is usable by single databases, elastic pools, and managed instances.
• The vCore model also allows access to different hardware configurations, which impact the types of available processors, the maximum number of vCores, and the amount of memory allocated per vCore.
• Like DTU configuration, vCore capacity selections are limited to predefined classes within a service tier. 
• When using the General Purpose service tier only, you must also select from 1 of 2 compute tiers.
• Provisioned compute is selected by default.
• This means that the selected number of vCores will always be directly allocated to your Azure SQL solution
• They are all actively in use or not, meaning that you will be paying for all of those vCores, whether your solution is using them or not.
• The alternative is to use serverless compute, which is only available to single databases, and again, only when using the General Purpose service tier.

vCore hardware configurations.

Your vCore hardware configuration can be easily changed via the Azure portal. vCore hardware configurations define a few important limits that impact your workload performance, and like many other resource configuration settings, may be changed at any time.

The Gen5 hardware configuration 

• It is the default configuration for new deployments and is available for all service tiers.
• The Gen5 configuration is intended for general computing needs and uses what Microsoft considers to be a typical CPU to memory ratio.
• There is a Gen4 hardware configuration, which is still supported for existing deployments where it is already in use, but it is being phased out and is no longer available for new deployments.

The FSv2 series hardware configuration 

• It is intended for workloads that would benefit from compute-optimized hardware, and has a higher CPU to memory ratio when compared to Gen5.
• While there is less memory per vCore when compared to Gen5, FSv2 can provide similar computing capabilities using fewer vCores than Gen5.
• The FSv2 series is only available when using the General Purpose tier.

The M-Series hardware configuration:

• It is memory optimized with a higher memory to CPU ratio compared to Gen5.
• The M-series is available only when using the Business Critical service tier, but it does not support the zone redundancy option provided by that service
• tier. 

when using the provisioned compute tier, you will be billed per vCore hour, regardless of how many of those vCores your solution is actually using. If your solution's workload is fairly consistent and you feel you're making good use of what you have configured, then this might not be a problem at all.

vCore serverless compute tier

• If we select serverless as our vCore compute tier, Azure SQL will automatically scale the number of vCores allocated to our database as needed within minimum and maximum limits that we define.
• This allows our database to use and pay for only the number of vCores needed to satisfy our database's current workload.
• In this compute tier, billing is per vCore second instead of per vCore hour.
• The serverless compute tier is only available for single databases operating in the General Purpose service tier and only supports the Gen5 hardware configuration.
• By using the serverless tier, we should be able to make the billing charges for this database go from something like this, to something more like this,
• where the number of allocated and thus billable vCores is a much closer match with our database's workload demands.
• Another feature of the serverless compute tier is auto-pause.
• After a certain length of time passes while your database has had no activity whatsoever -- no connections, no CPU activity, no management activity from Azure -- auto-pause will stop the database, which means that there will be no compute charges applied while the database has stopped.
• The database will be resumed automatically for any type of activity, again, even management activity from within Azure that requires the database to respond, such as automated backups.
• This also means that the database will be unavailable for the initial connection attempt while it has stopped.
• Azure services and tools intrinsically apply retry logic when connecting
• to other Azure services, you will be responsible for incorporating retry logic into any of your own
• applications that will use your serverless database.
• Auto-pause is enabled by default for databases using the serverless compute tier. If you disable auto-pause, when your database has no activity,
• then you will still be charged the per vCore second rate for the minimum number of vCores that you've configured for that serverless database.

Elastic pools in vCores?

• They pretty much work the same way with vCores as they do with DTUs, in that vCores configured for an elastic pool are dynamically allocated to member databases as needed within the configured per-database limitations. 
• If desired,elastic pools using vCores may be configured to allocate only partial vCores with minimum per-database vCore settings of one half, or even one quarter vCore, as available selections.

How exactly do the 2 purchasing models compare to each other? Which one is better? 

• From the perspective of the Basic and Standard DTU service tiers, 100 DTS is approximately a single Gen5 vCore.
• From the Premium DTU service tier, 125 DTUs is approximately 1 Gen5 vCore.

Summary:

• The vCore purchasing model allows you greater control over hardware configuration compared to the DTU purchasing model, and it is supported by all Azure SQL platform-as-a-service offerings.
• The serverless compute tier is available only to Azure SQL single databases using the General Purpose service tier. That's it for our purchasing models.

Reference: vCore purchasing model - Azure SQL Database | Microsoft Learn