This is a part of a Series “Stairway to being an Azure SQL DBA“, in which I am planning to cover everything related to working as an Azure SQL DBA.
In one of the previous blogs we saw the difference between a Single database and an Elastic Pool.
If you have gone through my previous blog you get the gist of Elastic Pool, which is, it is a Pool of resources that we create and allocate databases to use this pool instead of providing them their own set of resources.
There is very high limit to how many different databases can use the same Elastic Pool but always consider the peaks they are making. The time and utilization is important in deciding the Pool size so that it is big enough to support the different databases hitting peak at the same time.
The SQL Database option remain the same as far as it’s working and settings are concerned, it doesn’t effect the Backups retention, Geo-Replication, Sync or Azure Search. The only difference between a Single Database and an Elastic Pool database is the resource allocation.
A case study when implementation of Elastic Pool makes sense.
In the above chart we can see the 5 databases for which DTUs reaches to ~40 sometime in a day but the aggregate for all the databases combined never reaches 80 DTUs.
The pricing for 5 50 DTUs databases is like below:
And when creating an Elastic Pool for the same set of databases having maximum DTU limit of 100, the cost is as below.
So we are saving $140 per month for just 5 databases in our environment.
In Elastic Pool the main limitation is for number of databases and maximum DTU that each database can have (in case of DTU model). Check this link for limits in DTU model and this link for limits in vCore model.