This post will go over how Elastic pools can help reduce your database costs in Azure. Elastic pools become more worthwhile if you have multiple Azure SQL Databases on your SQL Server.
Note how I said SQL Server and not Azure Subscription. An Elastic pool runs on a single SQL Server not a whole subscription.
When looking at prices I have picked UK South as the region for my resources so you can get the satisfaction of seeing a cheaper price when you pick a different region. UK South is an expensive region, picking the right region matters and can help lower costs, as mentioned in my previous post: https://mattou07.net/posts/how-to-host-a-simple-umbraco-site-in-azure-as-cheap-as-possible/
Acronym of this post
DTU stands for Database Transaction Unit and we will be using this as our purchase model when discussing performance levels. You may find the vCore model more suitable depending on your circumstances.
Quoting the docs: “A database transaction unit (DTU) represents a blended measure of CPU, memory, reads, and writes. The DTU-based purchasing model offers a set of preconfigured bundles of compute resources and included storage to drive different levels of application performance. If you prefer the simplicity of a preconfigured bundle and fixed payments each month, the DTU-based model might be more suitable for your needs.”
However, I highly suggest you look at using the vCore model as it provides greater transparency in the hardware details, read more here. For running this website, I am using the DTU based model as I don’t need to fine tune the hardware configuration, it’s just a simple blog website. You might find better performance using the vCore model.
Pricing disclaimer
All pricing is obtained from the Azure Pricing calculator, when creating the resources, you may be able to tweak the values of resources and lower your cost. Again, I am using UK South as my region, I suggest you use another region such as North Europe.
What is an Elastic pool?
Taking the direct quote from the docs, “SQL Database elastic pools are a simple, cost-effective solution for managing and scaling multiple databases that have varying and unpredictable usage demands. The databases in an elastic pool are on a single Azure SQL Database server and share a set number of resources at a set price. Elastic pools in Azure SQL Database enable SaaS developers to optimize the price performance for a group of databases within a prescribed budget while delivering performance elasticity for each database.”
It is a way to reduce cost if you are hosting multiple databases on your Azure SQL server. The databases share a pool of resources instead of having their own pool which enables you to pay a near fixed price instead of on an individual basis. This way you get more value for money as more resources are utilized and not wasted. It can become really expensive if databases are scaled on an individual basis. An elastic pool will dynamically scale databases individually in the pool depending on demand.
Reasons to NOT use Elastic pools
To save you time reading this I thought I would start with the bad, if you have a single SQL database on your Azure SQL Server (or even your whole subscription) there is no point getting an elastic pool. You are better off just sticking your database inside a Service Tier or you could give Serverless a go. You can read more about it here. If I get the chance to use serverless I will blog about it. One thing I am wondering is how fast can Serverless switch a database from inactive to active when demand spikes.
Next, if you have multiple databases and they simultaneously all have high usage demands you may find individually scaling them could work out cheaper for you. It really depends on your situation and I encourage you to use the Azure Pricing Calculator to work out an estimate. You can always migrate databases in and out of the pool very easily and compare costs.
Lastly, if you have databases distributed across different SQL servers, you will need to consolidate your databases into a single SQL server to allow them to share a pool. This may not be possible for some who have databases distributed around the globe in different servers.
Reasons to use Elastic pools
Now if you have multiple SQL databases hosted on a SQL server. Let’s say you have 20 databases and perhaps only a few are being utilized within a given timeframe. If you stick with service tiers, lets say we scale our databases to all be S0 which offers 10 DTUs per database, the bare minimum for standard. You are looking at around £279.57 per month for 20 databases each at S0.
However, if you configure an elastic pool and using the DTU purchase model give it the 100 eDTUs performance level we are looking at £210.25 per month and all databases inside will collectively share those 100 eDTUs. The elastic pool will dynamically scale each database based on the demand. This will allow a database with a high demand to pull more DTUs to cover the demand and less demanding databases will use less DTUs or none.
Even at small scale it can still work out better. Lets say we have 4 databases and scale them all to individually be at S2 tier which offers 50 DTUs it will cost around £279.57. However, as mentioned previously an elastic pool with 100 eDTUs will cost around £210.25 and still deliver similar performance as long as demand is not too high on all 4 databases.
It’s when you start to really reduce the performance level where an Elastic pool starts to become more expensive compared to service tiers. For example, at S0 which offers 10 DTUs will cost around £55.91 for 4 databases.
However a 50 eDTU Elastic pool will cost £105.13.
It’s cheaper to stick to service tiers in this scenario. However from experience, you will find S0 to be really slow for applications that are database intensive or have a lot of Umbraco content, if you are using Umbraco... There is no harm in adjusting tiers for your databases and I encourage you to experiment to see what works for you. Azure will provide their estimated cost when adjusting resources.
How to configure an Elastic Pool
If you already have your databases active don’t fret its very easy to incorporate an Elastic Pool into your existing infrastructure. However, if you have multiple SQL Servers and want to consolidate all of the databases into a single Elastic pool. You will have to migrate the databases so they sit on the same SQL server when creating a pool. There is no specific timeframe Azure is very flexible you can do the migration before or after.
Let’s begin, in the Azure portal look for Elastic pools and you will be greeted with this page:
Click Create SQL elastic pool to start.
Then setup your resource group, Elastic Pool name and pick the SQL server containing your databases.
Then click Configure elastic pool, here we will decide the performance level of our pool. By default, it will be set to using vCores. Again, this allows you to be more specific about the specs you want for your pool. However, for the sake of simplicity we will stick to the Standard tier. You can find this by clicking “Looking for basic, standard, premium?”:
Here we can adjust the requirements we need for our pool. If we set the DTUs to be 50 and the max data size to 50GB were looking at £83.75 per month. Next, if we go to the Databases tab, we can start to add our existing databases to the pool:
On the next tab we can specify how many resources should be allocated per database. However, it’s probably best to leave it as its default.
Once you are happy click Apply and then Review + Create to start provisioning the resources.
That’s it! You are now taking advantage of Elastic Pools to reduce your database costs by sharing resources. Provided the databases are sitting in the pool you can tell that a database is using the pool by looking at its pricing tier. Below our pricing tier is now saying Elastic General Purpose.
Real world examples
To show off a real world example, at Moriyama we have 27 databases sitting inside an elastic pool scaled using the vCore performance level model. We have a single core with 50GB of storage which costs an estimated £92.22:
However, you should note that we have a SQL server license which gives us a discount of 39%.
This is enough to host our clients Umbraco sites for preview purposes and for running iteration/sprints such as testing/performing Umbraco upgrades simultaneously.
Another example we have with a client is an Elastic pool that is using the Standard Tier at 100 eDTUs. They have 15 databases inside 12 which are production databases and in the past 7 days they have had a max resource utilization of 50%.
This is costing them around $224.75
Compare that to what they used to be paying when all the databases were using their own tiers ($900.24), elastic pools were the obvious choice for them. In both examples the resources are running in the North Europe region.
The End
Thanks for reading this post and making your way to the end. Give elastic pools a go, you can easily move the databases in and back out to the original service tier if you notice any issues. When moving databases into different tiers there usually isn’t any downtime as its still hosted on the same SQL server. It’s just now running on different hardware. Things are always moving in the cloud under the hood. Feel free to tweet me if you notice an improvement in costs or if something doesn’t make sense in this post. Thanks for reading!