<\/i>Guest Post<\/strong><\/p>Larry Silverman is the Chief Technology Officer at TrackAbout, Inc. (a Datacor company) and a long-time user of Azure SQL Database and SQL Server. In this blog post Larry shares a novel open-source solution which addresses a core need for their business. Thanks, Larry! <\/div><\/em><\/p>\n TrackAbout<\/span><\/a> is a worldwide provider of SaaS applications for tracking reusable, durable, physical assets like chemical containers and gas cylinders. With over 22 million physical assets tracked across 350 customers, each with their own Azure SQL database, optimizing our infrastructure for both cost and performance is a critical, ongoing mission.<\/span><\/p>\n Our journey with Microsoft technologies goes back to our founding in 2002. We started by racking our own servers, moved to managed hosting, and finally migrated to Azure in 2016 to gain more control and scalability. A core part of our architecture today is Azure SQL Database <\/span>elastic pools<\/span>.<\/span><\/p>\n When <\/span>Azure SQL Hyperscale elastic pools<\/span><\/a> was <\/span>announced<\/span><\/a>, we were intrigued. The promise of scaling up and down in just a few minutes<\/span> seemed ideal for our largest, most demanding customers. It offered potential improvements in both performance and cost. However, we discovered a key limitation: Microsoft didn\u2019t provide built-in autoscaling for Hyperscale elastic pools.<\/strong><\/span>\u00a0<\/span><\/p>\n That limitation led us to create <\/span>AutoScaler<\/span><\/b><\/a>, the open-source solution we\u2019re sharing with you today. This post will walk you through our approach for auto-scaling Hyperscale elastic pools and show how you can use it to optimize your own Azure SQL Hyperscale deployments.<\/span><\/p>\n The AutoScaler is a timer-triggered Azure function written in C#. It’s designed to be lightweight and efficient. A single instance can manage multiple elastic pools on the same Azure SQL Server, or you can run multiple instances of the function for different servers. You can find the code in <\/span>our GitHub repo<\/span><\/a>.<\/span>\u00a0<\/span><\/p>\n Instead of requiring a separate database to store metrics, the AutoScaler makes decisions using the historical data found in the <\/span>sys.dm_elastic_pool_resource_stats<\/span><\/a> view. This view provides about <\/span>40<\/span> minutes of historical readings, which is plenty of data to make informed scaling decisions. Scaling commands are automatically recorded in <\/span>the Azure SQL server\u2019s <\/span>sys.dm_operation_status<\/span><\/a> view, and also in the<\/span> Azure Activity Log. We also provide an option to log scaling decisions and the data used to make those decisions to a SQL table for long-term analysis.<\/span>\u00a0<\/span><\/p>\n Based on our nine years of experience running elastic pools, we chose to monitor these four key metrics for our workload:<\/span>\u00a0<\/span><\/p>\n Your workload might be different than ours. The function is extensible, so you could, for example, add monitoring for <\/span>Log IO Percentage<\/span> if that’s a bottleneck for your application.<\/span><\/p>\n The core of the AutoScaler is its hysteresis<\/a>-based scaling logic, which prevents “thrashing” (rapidly scaling up and down). We delay scaling decisions until metrics have remained above or below a threshold for a sustained period.<\/span><\/p>\n To do this, we measure averages over two sliding windows:<\/span>\u00a0<\/span><\/p>\n When deciding whether to scale <\/span>up<\/span><\/b>, we check if a metric has breached its high threshold in the short window. But we don’t act immediately. We wait to see if the long-window average <\/span>also<\/span><\/i> exceeds the threshold. If only the short window is high, the scaler waits, as it might be a temporary burst.<\/span>\u00a0<\/span><\/p>\n When deciding whether to scale <\/span>down<\/span><\/b>, we require that <\/span>all<\/span><\/i> four metrics remain below their “low” thresholds across both the short and long windows before we reduce capacity.<\/span>\u00a0<\/span><\/p>\n This logic can be summarized as follows:<\/span>\u00a0<\/span><\/p>\n You can configure much of this, including the high\/low thresholds for each metric, the lookback windows, and the floor\/ceiling vCore levels to ensure you stay within your budget.<\/span>\u00a0<\/span><\/p>\n We’ve tried to make it as easy as possible to get up and running. The project’s GitHub repository has all the details, but here’s the gist:<\/span>\u00a0<\/span><\/p>\n We strongly encourage you to explore the docs, code and unit tests, and run your own load test to get comfortable with how the AutoScaler behaves in your environment.<\/span> There are load testing instructions in the repo.<\/span><\/p>\n The following flow chart illustrates the logic of the autoscaler (click to enlarge) each time the timer trigger fires.<\/span><\/p>\n \u00a0 AutoScaler works by invoking the standard Azure SQL elastic pool scaling APIs. When the pool scales, client connections are dropped<\/strong>. Your client code must be built for resiliency to handle this disconnect and retry interrupted transactions. Refer to the documentation<\/a> for guidance on how to do this correctly. There are libraries that can help.<\/span><\/p>\n As with any cloud resource,<\/span> Azure SQL <\/span>elastic pools<\/span> can incur <\/span>very high costs <\/span><\/b>if not used appropriately<\/span><\/b>. You are solely responsible for any costs you incur by using this code. We strongly recommend that you study the project, review the unit tests, and run your own load tests to ensure the AutoScaler behaves in a manner you are comfortable with before deploying to production.<\/span>\u00a0<\/span><\/p>\n This project was inspired by Microsoft’s own <\/span>past work<\/span><\/a> on autoscaling, and we’re thrilled to contribute back to the community. We welcome your feedback, suggestions, and contributions. Check out <\/span>the project on GitHub<\/span><\/a>, and let’s work together to make it even better.<\/span>\u00a0<\/span><\/p>\n Happy Scaling,<\/span><\/p>\n Larry Silverman<\/span>\nChief Technology Officer<\/span>\nTrackAbout, Inc.<\/span>\u00a0<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" TrackAbout is a worldwide provider of SaaS applications for tracking reusable, durable, physical assets like chemical containers and gas cylinders. With over 22 million physical assets tracked across 350 customers, each with their own Azure SQL database, optimizing our infrastructure for both cost and performance is a critical, ongoing mission. Our journey with Microsoft technologies […]<\/p>\n","protected":false},"author":184097,"featured_media":81,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,594],"tags":[],"class_list":["post-5150","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure-sql","category-hyperscale"],"acf":[],"blog_post_summary":" TrackAbout is a worldwide provider of SaaS applications for tracking reusable, durable, physical assets like chemical containers and gas cylinders. With over 22 million physical assets tracked across 350 customers, each with their own Azure SQL database, optimizing our infrastructure for both cost and performance is a critical, ongoing mission. Our journey with Microsoft technologies […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/posts\/5150","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/users\/184097"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/comments?post=5150"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/posts\/5150\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/media\/81"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/media?parent=5150"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/categories?post=5150"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/tags?post=5150"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Solution: The AutoScaler Azure Function<\/span><\/h2>\n
Key Features at a Glance<\/span><\/h2>\n
\n
How It Works: Metrics and Logic<\/span>\u00a0<\/span><\/h2>\n
Metrics Monitored<\/span><\/h3>\n
\n
\n
\n
\n
Hysteresis-Based Scaling Logic<\/span>\u00a0<\/span><\/h3>\n
\n
\n
\n
\n
Getting Started<\/span>\u00a0<\/span><\/h2>\n
\n
\n
\n
Logic Flowchart<\/span>\u00a0<\/span><\/h2>\n
![\"flowchart](\"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-content\/uploads\/sites\/56\/2025\/06\/flowchart-580x1024.png\")
<\/a><\/span><\/p>\nWarning<\/h2>\n
Disclaimer<\/span><\/h2>\n
Join the Community<\/span>\u00a0<\/span><\/h2>\n