A quick PSA on the behaviour of Serverless Azure SQL DB space reporting in the Azure Portal.
I recently had to shrink a large Azure SQL DB for cost savings after a deleting a lot of data and noticed the Portal space usage pie chart seemed off. I was pretty sure it had a few hundred GB of used space and around 2TB of allocated space, but when looking at the chart on the paused database before waking it up for a shrink session, it seemed to have miraculously compacted…

Huh? Ok, maybe it shrunk itself thanks to some new Azure backend wizardry. That wouldn’t surprise me. I’ve also seen odd behaviour when shrinking Azure SQL DBs before – specifically, a piecemeal shrink script making very slow progress, only for the database to suddenly shrink 100% of excess allocated space when no shrink operation was visibly running. (That one was identified as a bug at the time.)
But…that wouldn’t explain the reduced data space used. Let’s wake ‘er up and see what’s going on…

Ok, yep, that’s over 2TB allocated as I suspected.
The Portal still showed the 78.53GB used/allocated at this point, but waiting 10 minutes and viewing again showed the correct values – 157.5GB used, 2.23TB allocated;

So, looks like sometimes you can’t trust the data storage numbers in the Portal for a paused Serverless Azure SQL DB at the moment. And as it doesn’t appear to have been reported yet, that’s my first Feedback item. Woohoo!