Making SQL sense

+44 (0)20 3051 3595 info@coeo.com
coeoClose

Making SQL sense

+44 (0)20 3051 3595 info@coeo.com

Careers

We're looking for people who share our commitment to excellence in Microsoft's data platform to join us consultants working on exciting business intelligence, analytics, and SQL Server projects on-premises and in the cloud.

New vCore purchasing option for Azure SQL Database

The Coeo Blog

Managed Instance is now in public preview and with it is a purchasing option we haven't yet seen with traditional Azure SQL Database offerings, known as the vCore purchasing model.  Earlier this month, Microsoft announced this model is now available in preview for Single Database and Elastic Pool deployments of Azure SQL Database.  So what does this mean, why would I choose this purchasing option and could this signify the beginning of the end for the Database Transaction Unit (DTU)?

What's changed?

Using the vCore purchasing model, Microsoft defines how many vCores and how much memory you get for your money.  There are two service tiers; General Purpose and Business Critical, which are differentiated by availability, storage and throughput.  Each service tier provides five separate performance levels which are differentiated by vCores and memory.  The first thing that strikes you is that for every vCore you get 7GB of memory and as a result the cost doubles from each level to the next.  It's also important to note that you now pay for the storage you provision which is priced on a per GB per month basis.  If you find that your database size has grown, you can increment the storage by 1GB increments - up to the maximum allowed for each service tier.  I/Os and backup storage are also chargeable on the same basis (both free during preview).  I recommend this article for a full breakdown of service tiers and performance levels.

It's worth mentioning that the DTU purchasing model is still available for Single Database and Elastic Pool deployments.  Microsoft has even gone as far as committing to the future of the DTU model, with good reason too, as we'll discuss later.  If you're wondering what a DTU is exactly; it's a blend of compute, storage and I/O resources that together determine the performance level of a given service tier.  For more information, I recommend reading this article.

Why would I use it?

One of the most common questions I get asked by customers is, "what would be the running costs once I've migrated to Azure SQL Database?".  To date, addressing this question upfront has been difficult, in some cases more so than the technical migration challenges.  We're simply not used to talking in DTUs because it's an abstraction we have no control over nor can we break down reliably into its constituent parts.  Whilst this problem hasn't been completely removed, the fact that Microsoft now exposes the vCores and memory that comprises a performance level should make it easier to size workloads and estimate upfront running costs.  Needless to say, your workload still needs testing to refine the estimate and verify performance, but at least we now have a language we can all speak.

We've all worked with an application where the storage required for its database is relatively high compared to its compute requirements (and vice versa).  Under the DTU purchasing model, when you configure a Single Database or Elastic Pool, the "included storage" is rolled up into the cost.  So, if I configure an S3 database, I pay for the full 250GB that comes with it.  Until the introduction of storage add-ons in August 2017, we hadn't been able to independently scale storage and compute under this purchasing model.  Before then, if you had a large database that exceeded 1TB that was light on compute needs, you would have to scale the database to a P1 and spend an extra £200 a month for compute you didn't need.  Therefore, this confirms the unique selling point for the vCore purchasing model.  Customers can select a performance level and then precisely configure the storage needed for the database, which can increase over time.  In other words, I can scale the storage and compute independently and only pay for what I need!

Finally, an additional significant benefit of the vCore purchasing model is that Azure SQL Database deployments can now be licensed using the Azure Hybrid Benefit for SQL Server.  This means customers with active Software Assurance (SA) for on-premises SQL Server Enterprise and Standard Edition core licenses can transfer this core-based license entitlement and enjoy savings of up to 30 percent on Azure SQL Database deployments.  For information on pricing, see this Microsoft Azure pricing page.

Summary

The Azure SQL Database vCore purchasing option unifies the purchasing model for Single Database and Elastic Pools with the newest addition to the family; Managed Instances.  It's a positive step, as it now gives you a choice between buying pre-configured units where the cost is predictable versus a set of options that favour flexibility and control.  Microsoft even provides guidance for customers who want to migrate workloads between the models; just in case you want to change later on. 

It's not for everyone though; many of you may still find the predictable nature of the DTU purchasing model fits your requirements.  Many organisations will be on a cloud journey and operating hybrid solutions for some time.  As such, the flexibility and predictability to migrate database workloads to Azure SQL database will accelerate migrations for many organisations. If you have existing license investments on-premises and require a much finer-level of control over the configuration, the vCore purchasing model will provide you with a flexible method to migrate to Azure SQL Database.

Subscribe to Email Updates