Azure elastic database pool scaling duration query

Question

We currently have an elastic pool of databases in Azure that we would like to scale based on high eDTU usage. There are 30+ databases in the pool and they currently use 100GB of storage (although this is likely to increase).

We were planning on increasing the eDTU's allocated to the pool when we detect high eDTU usage. However a few posts online have made me question how well this will work. The following quote is taken from the azure docs - https://docs.microsoft.com/en-us/azure/sql-database/sql-database-resource-limits

The duration to rescale pool eDTUs can depend on the total amount of storage space used by all databases in the pool. In general, the rescaling latency averages 90 minutes or less per 100 GB.

If i am understanding this correctly this means that if we want to increase the eDTUs we will have to wait for on average 90 minutes per 100GB. If this is the case scaling dynamically won't be suitable for us as 90 minutes to wait for an increase in performance is far too long.

Can anyone confirm if what i have said above is correct? And are there any alternative recommendations to increase eDTUs dynamically without having to wait for such a long period of time?

This would also mean if we wanted to scale based on a schedule, i.e. scale up eDTUs at 8am we would actually have to initiate the scaling at 6:30am to allow for the estimated 90mins of scaling time - if my understanding of this is correct.

Answer 1

When you scale the pool eDTUs, Azure may have to migrate data (this is a shared database service). This will take time, if required. I have seen scaling being instant and I have seen it take a lot of time. I think that Microsoft's intent is to offer cost savings via Elastic Pools and not the thru ability to quickly change eDTUs.

Answer 2

The following is the answer provided by a Microssoft Azure SQL Database manager:

For rescaling a Basic/Standard pool within the same tier, some service optimizations have occurred so that the rescaling latency is now generally proportional to the number of databases in the pool and independent of their storage size. Typically, the latency is around 30 seconds per database for up to 8 databases in parallel provided pool utilization isn’t too high and there aren’t long running transactions. For example, a Standard pool with 500 databases regardless of size can often be rescaled in around 30+ minutes (i.e., ~ 500 databases * 30 seconds / 8 databases in parallel).

In the case of a Premium pool, the rescaling latency is still proportional to size-of-data.

This Azure SQL Database manager promised to update Azure documentation as soon as they finish implementing more improvements.

Thank you for your patience waiting for this answer.