tl;dr: if you use Azure SQL DB Hyperscale’s auto-scaling, it’s probably not cutting your bill down because like SQL Server, Hyperscale doesn’t automatically relinquish memory, and it’ll be up to you to manually manage your own memory if you wanna cut your bill.

Now for the long story.

Microsoft’s Azure SQL DB Hyperscale has an auto-scaling option that’s supposed to automatically scale up and down. It’s perfect for bursty workloads like Have I Been Pwned, a free online service where you can put in your email address and see if your login details have been leaked. (Mine’s been part of 44 data breaches, which is one of the many reasons why I use 1Password to create separate logins for each web site, and sync my logins across all devices, plus manage my one-time passwords.)

Have I Been Pwned’s back end architecture relies on Azure SQL DB Hyperscale for data storage, and uses autoscaling to automatically add more horsepower (like when there’s a big breach to import), and cut horsepower during low-load periods to save money.

However, Stefán J. Sigurðarson discovered why their bill wasn’t going down. It turns out that Hyperscale’s automatic cost savings only kicks in when your CPU usage is low and when your memory usage is low, too. That’s where the problem comes in.

Microsoft SQL Server uses all your available memory by default, and doesn’t give it up automatically. I’m simplifying – there are some small guardrails, and SQL Server will back down its usage when other apps fire up and demand memory. But the vast majority of users will look at the vast majority of servers and say, “Whoa, SQL Server sure is using a lot of memory, and it never seems to go down.”

That’s a good thing for well-managed database servers (as I explained in that post above, more than a decade ago) – and that design served Microsoft well for decades. However, it’s a problem for the cloud, especially for cloud services that are supposed to automatically scale up and down based on demand. Azure SQL DB Hyperscale is built with Microsoft SQL Server’s code, and inherits some of those design choices.

Azure SQL DB Hyperscale’s memory documentation says they fixed SQL Server’s problem, saying things like:

Unlike provisioned compute databases, memory from the SQL cache is reclaimed from a serverless database when CPU or active cache utilization is low.

Except as Stefán discovered and documented in his post, that doesn’t appear to be the case. Stefán’s post explains how to work around it by creating a stored procedure to manually down-scale your Hyperscale database based on low demand, and to run it in an Elastic Job. Good stuff. You should subscribe to his blog (button at the top right of his site) because it’s hard to find folks publicly sharing real-world Hyperscale knowledge, especially at scale.

I do expect Hyperscale’s behavior to change as it gains more public awareness, and just over time in general, Microsoft’s strategy for how they scale down (and scale up) will change. That’s just a normal part of any development process, and hopefully they document those changes and share ’em with customers.