This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(16, 26%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBO%3C/text%3E%3C/svg%3E)
Hello,
I'm looking at specifying Azure SQL single databases using the vCore purchasing model, specifically standard-series Gen5 serverless.
This article on resource limits shows that each compute size specified in terms of vCore capacity has an associated minimum capacity. For example, GP_S_Gen5_10 states minimum vCore is 1.25.
Minimum capacity, apart from being bounded by the limits associated with capacity, otherwise appears to be flexible. For example, I can specify a GP_S_Gen5_10 serverless database and then in Azure Portal drag the min slider anywhere between 1.25 and 10.
My question is, what's the effect on resource limits of specifying a serverless database with a higher minimum capacity than required, i.e. outside the documented min/max configurations, e.g. GP_S_Gen5_10 with minimum capacity 4 rather than 1.25?
Is there any benefit of setting minimum capacity higher than the documented minimums required?
I would be expecting worse performance with a lower minimum capacity, since a lower minimum memory should mean that more memory is reclaimed, the database buffer cache is smaller and more queries need to retrieve data from storage. Also I'd expect that with a lower minimum capacity, there'd potentially be more scaling operations and if load balancing is required to satisfy that demand then scaling won't be instantaneous and requests could end up taking longer?
I was unable to verify that increasing that minimum capacity is having an impact on performance and resource limits.
I did a test on a serverless database, altering scale and then querying the sys.dm_user_db_resource_governance view.
I set max vCores at 10, min vCores 1.25, and queried the resource governance view. Then on the same database, adjusted min vCores to 4, leaving max vCores at 10, and waited for that scaling operation to complete. The resource governance view gave exactly the same result with identical values of min_cpu, min_memory, primary_group_min_io, primary_group_min_cpu. In fact, the date and time of the last reconfiguration last_updated_date_utc didn't change.
I repeated this test at other capacities e.g. comparing 0.5-4 to 1.25-4 and got the same result.
The settings only updated when altering max vCores, where slo_name updates too. I don't see any difference in values when only adjusting the minimum capacity setting.
Thank you.
@Ben Outram If your question has been answered, please click Accept answer and Yes to help others looking for answers to similar questions.
Regards
Geetha
The minimum capacity affects billing and not performance. It is memory and not CPU the biggest performance factor with serverless as memory is reclaimed on serverless on more aggressive way compared with other Azure SQL flavors, and you cannot control that memory behavior. Query waits are more related to memory on Serverless tier than with anything else.
Hi, thanks for replying and thanks for the notes on memory management which is useful. :)
I'm not sure I fully understand what you mean by minimum capacity affecting billing and not performance.
If I set a maximum of say, 10 vCores to get a GP_S_Gen5_10 database, I'm required to set a minimum capacity of 1.25, and the resource limits in terms of CPU, memory, IOPS etc. for that combination 1.25-10 are documented.
But for that same maximum setting of 10 vCores I can also increase minimum capacity above 1.25 all the way up to 10 and it will still deploy but bill a new higher rate of vCore seconds.
I want to check that increasing the minimum capacity does allow for some performance benefit otherwise it would be pointless to raise minimum capacity and get billed extra but see no benefit compared to using the lower required minimum capacity value and allowing the database to scale.
I have not seen any performance gain on increasing the minimum capacity. However, that minimum does have impact in billing.
If, for example, the amount of CPU used is less than the minimum amount provisioned as set by the min vCores and min memory, then the minimum amount provisioned is billed.
If a serverless database is paused, then the compute bill is zero. If a serverless database is not paused, then the minimum compute bill is no less than the amount of vCores based on max (min vCores, min memory GB * 1/3).
Hi, @Ben Outram Welcome to the Microsoft Q&A platform, thanks for posting the question.
The min vcore configuration for serverless specifies the lower bound of the compute auto-scaling range. The higher the min vcore config, the more resources that will be continuously available independent of usage. So, this setting helps to reduce the performance impact from compute warm-up during scale-up. To clarify, the min-max vcore config is not only an index into the min-max scaling limits for CPU, but also for memory including caches like the buffer pool for data pages and precompiled query plans. And it’s the min memory limit for these caches that generally provides the greatest benefit in reducing compute warm-up impact.
The resource governance settings in the DMV do not change during auto-scaling. For example, memory scale-up is unthrottled up to the max memory limit which doesn’t change. Memory scale-down in serverless is triggered during low or idle usage periods (unlike provisioned compute), but does not drop below the min memory limit which also doesn’t change. Memory reclamation occurs through an alternative internal mechanism by reducing memory targets to induce memory pressure. Cache evictions are optimized by generally selecting cache entries that are the least costly to rehydrate in terms of perf impact. Nevertheless, there is still a price-perf trade-off in serverless due to memory reclamation and the min memory config provides some control over that impact.
Regards
Geetha