PaaS is great!! And with the announcement of a serverless Azure SQL compute tier, in preview, we have yet another pricing option that can help us cut costs.
The Serverless purchasing model comes with a few benefits,
- Billing by the second (not hour as it is in the provisioned option)
- Compute auto-scaling vs pre-allocated (only billed for the cores you are using based on activity)
- Most important the ability to pause the server if inactive (not billed at all for compute during inactive times)
So to summarize, if our database or it goes idle or scaling requirements, dynamic remember, change the billing will be by the second. If the DB is inactive for a configurable duration (minimum 1 hour) you are not billed for compute – until it becomes active again.
This won’t work for all architectures but worth considering if you have a workload to load data and then only work with it periodically, have a single database that has periods of inactivity or varied activity, or maybe a development environment where warm-up speed is not important.
Finding severless in the portal
1 – Go to create a new “SQL Database”
2 – Under Compute + Storage select configure database
3 – Here you will have the option to select the service and compute tiers
4 – And after selecting serverless, you will have the option to select min and max vCores, set the auto-pause delay and configure the max data size.
Deeper look at DTU and vCore
Currently, Azure SQL has different purchasing models (DTU, vCore) which have different service tier offerings (general purpose, hyperscale, business critical for vCore and basic, standard, premium for DTU). And deployment options which are Managed, Elastic, Single. For serverless, we will look at the vCore, single database option with the compute tier set to Serverless.
- Virtual Core (vCore) – this purchasing model provides a more intuitive way to match on-premise performance with the cloud. vCore represents a logical CPU available to you and can be based on different generations of hardware allowing the scaling of CPU/compute and storage separately. So when provisioning the resource you specify the number of vCores and also the Max data size for your DB, each can be scaled separately. Also has the option to use Azure Hybrid Benefit for SQL Server. vCore supports the general purpose, hyperscale and business critical service tiers for single databases, elastic pools, and managed instances.
- DTU – this model also bundles computer, storage, and IO operations meaning they scale together. DTU supports basic, standard, and premium service tiers for both single databases and elastic pools (no managed instances). Choosing DTU is a nice way to use preconfigured bundles of resources (CPU, memory, IO) to match application performance needs.
For a more detailed look at DTU vs vCore see the Microsoft article https://docs.microsoft.com/en-us/azure/sql-database/sql-database-purchase-models
Converting from DTU to vCore
To convert from the DTU-based purchasing model to the vCore-based purchasing model, select the compute size by using the following rules of thumb (https://docs.microsoft.com/en-us/azure/sql-database/sql-database-purchase-models):
- Every 100 DTUs in the standard tier require at least 1 vCore in the general purpose service tier.
- Every 125 DTUs in the premium tier require at least 1 vCore in the business critical service tier.
It’s great to see Microsoft listen to customers and to release features that make us more productive and keep billing manageable.
Fore more information please read: