Azure SQLDB Basic, Standard and Premium Tiers - Quick glimpse and first impressions
After the recent BUILD conference, Microsoft team responsible for SQL Database development clearly accelerated on disclosing new features and capabilities, several of them awaited since a long time ago, but finally we have now in preview, as you can read in the official announcement below, published on April 24th:
Azure SQL Database introduces new service tiers
Looking at the above content, two pillars are evident: performance predictability and enhanced high availability and disaster recovery features. In my personal list of nice to have or missing features, built on my experience working with Microsoft Global ISVs, these new announced features are intended to address the top items contained there. However, for the end user, what is really changing compared to traditional Web/Business edition SKUs? There are three areas to carefully examine, that is Cost, Performance and HA&DR. Let me start my discussion bringing up to your attention the following table on what is new in the above announcement:
NOTE: If you tested Premium SKUs before and getting confused about missing P4 performance level, do not worry since it has been renamed to P3.
COST
With the introduction of Basic, Standard and Premium SKUs, billing for Azure SQL Database moved from a per-space-used model to a modern tiered offering where for each tier you will have different guaranteed performance levels and HA&DR features. Let me make an example: with previous Web/Business model, having 100 databases of 1 GB each was roughly (not exactly) the same as one big 100GB database from a pure cost perspective. With the new tiers, this is not true anymore, you will pay per database capabilities, which also include but not limited to maximum database size. In the last two years I saw many partners and customers using a multi-tenancy and sharding model based on 1 DB <-> 1 Tenant, now this require a mind shift and a new consolidation approach: once you decide to use a specific tier, let’s say Standard for example, in order to optimize costs, you will need to pack Together as many data (tenants? users?) as possible in order to reach the maximum database size of 250GB, obviously if resources will be able to sustain the resulting workload. This is reflected in the official pricing page for Azure SQL Database as reported below for Web/Business editions vs. Basic/Standard/Premium:
http://azure.microsoft.com/en-us/pricing/details/sql-database/#basic-standard-and-premium
Looking into this page, I also discovered a new Interesting billing detail not specific to Azure SQL Database but valid for Azure in general:
Why that edit-box on regions? Well, I just discovered that now Azure can be priced differently based on the region in the world where you allocate you cloud resources and services… Uhm… nice considerations now may apply on whether is more convenient to deploy your assets! Now, moving forward on the cost considerations, if you carefully look at the costs of higher Premium SKUs, you may be surprised by the prices; if you consider them too high, especially compared to SQL Server in IaaS VMs, please consider the points below and think again:
- Every SQLDB database is replicated three times to ensure high-availability and disaster recovery inside the same datacenter, but you will pay only one.
- If you deploy SQL Server in Azure IaaS VMs in highly available configuration, you will have to create at least 3 VMs for AlwaysOn Availability Group configuration (AG), plus at least two additional VMs for Active Directory Domain controllers since it’s required by AlwaysOn AG.
- Every SQLDB database is automatically backed up by Azure and retained up to 35 days (depending on the SKU) and you don’t pay for the storage required, while with IaaS you have to take care of this operation and pay for the extra storage.
- In SQLDB there is no maintenance cost nor maintenance activity required, Azure will take care of (almost) everything.
- At least today, you can’t have SQL Server AlwaysOn AG spanning different Azure datacenters while with SQLDB Geo-DR you can.
- You can easily deploy a high-available and geo-replicated SQLDB database in seconds, while a manual AlwaysOn configuration will take hours and specialized skills.
For the Standard tiers, instead, I compared my actual SQLDB databases and using the calculator I realized that they are slightly cheaper, that’s nice since I also have new and enhanced features paying less.A final note on the new tiers: be aware that you will pay for SQLDB new SKUs also in preview, even if the price is reduced by 50% compared to the official price once the offering will be officially released.
PERFORMANCE
Your first question, especially if you already have at least on Web/Business edition database, could be something similar to this: the new tiers are more powerful than Web/Business editions? What is important here is not the processing power you will have with Basic, Standard and Premium tiers, but the fact that now you have guaranteed level of resources and performances that you didn’t have before! Speaking with several partners, I found a common misunderstanding, let me report here since I consider important for everyone to be aware. First of all, give a look at sessions and worker threads limits reported at the link below:
Azure SQL Database Resource Governance
http://msdn.microsoft.com/en-us/library/azure/dn338078.aspx
As you can read there, in Web/Premium editions, the maximum limit of concurrent requests is 180, beyond this limit, you will receive error 10928: the key point here is that 180 is the maximum value, but if the system is too busy, you could also have ZERO as the effectie resource level! In other words, there is no minimum guaranteed level of resources allocated for you, and here is where the new Basic, Standard and Premium SKUs are different: now you will be sure to use the entire amount of resources that each edition will guarantee, that is Minimum = Maximum. The important consequence of this new resource governance is that your application will have a more predictable performance feedback behavior, a more constant execution and response time.
Performance levels is a totally new concept and it has been introduced in SQLDB to address the #1 customer concern, that is the possibility to have predictable performances, then mitigating the fact that you are running your workload in a multi-tenant cloud platform where you share resources with your neighbors. Just to give you an idea, here is what these levels will offer you (http://msdn.microsoft.com/library/azure/dn741336.aspx):
There is something very interesting that is missing in the above table: did you notice that there is no indication of memory, CPU and IOPS? Yon can think that someone forgot to include there, but I have another explanation, not backed up by any official Microsoft statement,
that I consider interesting and worth sharing with you. Even if in the above table there are references to guaranteed physical resources (GBs, threads, sessions), if you create a new SQLDB database in the Azure Portal using the new Premium SKUs, you will clearly see that the term “DTU” is emphasized and is the only indicator shown for the level of performances you will have:
As you can read at the link below, DTU stands for “Database Throughput Units” and it is a clear method, at least in my opinion, to abstract the database performances from the underlying hardware resources used in Azure SQLDB. Even if in the future underlying Azure server hardware resources will change, you will still have the same database power and performances, but this time expressed in a new logical unit of measure that will better reflect what should be more important for you, that is transactions, not how many CPUs or RAM your virtual box will have.
Azure SQL Database Benchmark Overview
http://msdn.microsoft.com/en-us/library/azure/dn741327.aspx
As my last consideration on performances, let me bring upfront how performance SLA are measured, you can obtain this information from the previous table:
- Basic: Designed for applications with a light transactional workload. Performance objectives for Basic provide a predictable hourly transaction rate .
- Standard: Standard is the go-to option for getting started with cloud-designed business applications. It offers mid-level performance and business continuity features. Performance objectives for Standard deliver predictable per minute transaction rates.
- Premium: Designed for mission-critical databases, Premium offers the highest performance levels and access to advanced business continuity features. Performance objectives for Premium deliver predictable per second transaction rates.
In addition to the concept of guaranteed level of resources explained above, please don’t forget that now, with Premium SKUs, you will be able to have database of 500GB maximum size.
HA&DR
First of all, please welcome a new higher uptime SLA of 99.95% for all the new Basic, Standard and Premium tiers! Don’t be wrong, while the marginal improvement may seems small on a pure numerical perspective, it’s very important to reach (and in some cases surpass) the HA SLA offered by competitors, and also to offer the same level guaranteed by Azure Compute resources. I personally hope that also the Azure storage will provide in the future the same improvement over the actual 99,90% SLA level. A very important new feature for Basic, Standard and Premium SKUs is the possibility to have self-service restore, that is the possibility, using the Azure Portal, Power Shell or APIs, for database restore, as explained at the following link:
Azure SQL Database Backup and Restore
http://msdn.microsoft.com/en-us/library/azure/jj650016.aspx
Please pay attention to two important aspects: first of all different tiers will offer different retention periods. Secondly, only Standard and Premium SKUs will give you point-in-time restore capabilities, using Basic you will not have incremental backups, then only a restore from the last full back will be possible. As it probably happens also to you when testing Something new, I created and deleted several databases, then I noticed this (hidden ?) gem in the Azure Portal showing a new functionality:
Using this new tab, you will be able to restore a deleted/dropped database at no additional costs, essentially is very similar to the Windows Recycle Bin feature for deleted files! I will cover this functionality in more details in the near future, but for the moment, it is worth mentioning that you can restore to a point-in-time, depending on the SKU used:
Now, let me introduce the last new feature for new tiers in the HA&DR space, that is Active Geo-Replication:
Active Geo-Replication for Azure SQL Database
http://msdn.microsoft.com/en-us/library/azure/dn741339.aspx
You now have the possibility to asynchronously replicate transactions from one database to another, in a different instance and also in a different datacenter: the nice thing is that there is a guaranteed RPO < 5 minutes, but remember that this is a feature only available in the Premium edition. This feature is very useful not only for disaster recovery purposes, but also for read-only workload offloading since you can have up to 4 readable secondaries. Additionally, please note that you will pay for your secondaries and that there is no automatic failover since this is a disaster recovery mechanism, not intended for high-availability.
Final considerations
Regarding the new SKUs and the provided elasticity, here are some interesting notes based on my experience as an early adopter:
- Finally, I’m very happy to see that finally customers with paid Windows Azure Support plans and Microsoft Premier Support offerings can now get Microsoft support for the SQL Database also in previews, not only when generally available; this includes Azure SQL Database Basic, Standard, and Premium previews. Great and more than welcome policy change compared to the past, now customers can start using these important service improvements immediately with adequate support, but be aware that SLAs are not guaranteed until official final release.
- Elasticity is a key pillar in any cloud service, then also for SQLDB, you will be able to dynamically upgrade/downgrade from/to any SKU, but be careful with the time required to perform this operation the impact on performances if it is a production database. Additionally, changing SKU may requires internal copy of your database from one Azure host machine to another, no SLA here on how long it will take.
- During my tests, I immediately discovered that there is a limit on the number of SKU changes per day: you can only do that 4 times per day, excluding Web/Business intra-edition changes.
- Regarding the pricing, you are daily charged once per single database, depending on the highest SKU applied in that day: this means that you switch from Basic to Premium P1 (for example) you will be only billed one time based on Premium P1 rate and not both.
- You are initially limited to a quota of (2) databases per single SQLDB instance, as you can see in the screenshot below, you can raise it opening a call to the Azure Support and ask a quota increase:
Finally, let me speak shortly about the future of Web/Business editions: Azure SQL Database Web and Business will be retired in 12 months from April 24, 2014; you can have more details at the link below:
Web and Business Edition Sunset FAQ
http://msdn.microsoft.com/library/azure/dn741330.aspx
In the above link, there is a very important statement around the “old” Federation feature retirement:
The current implementation of Federations will be retired with Web and Business edition
Why is important? Well, almost everyone inside and outside Microsoft realized that, but until this announcement, we did not have official statement, now there is. However, there is an important consideration that must be done here: how customers and partners should replace Federation? It seems that there is no viable option today. Unfortunately, that is true, no immediate replacement for Federation in the recent announcements on new Azure SQL Database features, but I am pretty sure Microsoft will release something before the expiration deadline, stay tuned!
Looking forward to the next series of blog posts on Azure SQL Database, you can also follow me on Twitter ( @igorpag). Regards.