Our Azure SQL Database experiences severe performance degradation (40-50% slower transactions) whenever storage scales up automatically. We’re on the General Purpose tier with auto-scaling enabled, and when the database grows beyond 80% of allocated storage, Azure triggers automatic storage expansion. During this expansion, transaction processing times spike from 200ms to over 1 second.
The DTU utilization shows normal levels (around 60-70%) but queries just slow down dramatically. Connection pooling is configured with max 100 connections. We’ve tried implementing read replicas for reporting queries, but the primary database still suffers during storage scaling events.
SELECT TOP 10 query_hash,
AVG(total_elapsed_time/execution_count) as avg_time
FROM sys.dm_exec_query_stats
ORDER BY avg_time DESC
This query shows our transaction stored procedures jumping from 180ms to 950ms average during scaling. The performance returns to normal 20-30 minutes after scaling completes. How can we prevent this degradation?
We had this exact issue and found that the problem was compounded by our scaling policy. When you hit 80% storage, Azure not only scales storage but also adjusts some backend configurations. If you’re close to DTU limits too, this creates a perfect storm.
Our solution was to manually scale storage before hitting 80% threshold and to scale in larger increments (not letting auto-scale do small incremental increases). This reduced the frequency of scaling events from weekly to monthly.
Yes, DTU metrics don’t show the full picture during storage operations. Azure SQL Database has separate IOPS limits that aren’t directly visible in DTU measurements. During storage scaling, the backend temporarily reduces IOPS to safely expand the storage layer. This affects transaction log writes more than reads, which explains why your write-heavy transactions slow down.
You should be on Premium or Business Critical tier if you need consistent performance during scaling events. General Purpose tier doesn’t guarantee IOPS during maintenance operations.
Storage scaling in Azure SQL Database involves backend operations that can temporarily impact I/O performance. During the scaling operation, there’s a brief period where the database is reconfiguring storage allocation which causes increased latency for disk operations. This is expected behavior but shouldn’t cause 40-50% degradation.
Check if your queries are causing page splits or if you have fragmented indexes. These operations become more expensive during storage scaling.