JSBSF You are definitely solving a different problem than I am trying to. 🙂 I am glad you found a solution that works.
You can do what you need by comparing used vs. allocated, whereas I need to compare allocated vs MAXSIZE and they just don't make the latter available via TSQL for user databases from master.
We can get it using a PowerShell script to iterate through the databases in a pool and produce an aggregated result, but not from TSQL. We only need to get that data on a daily basis for now, so the 15 minute latency on the metrics are not a problem for us.
>They go cheap on us for testing and QA
True for almost everyone. 🙂 We scale the pool up during active testing and back down again when the testing is completed. But as data has grown over time, the lowest tier and number of vCores we can scale to has risen. I wish we had the ability to start and stop the pool instead as that would save us more money. We don't want to test using Serverless, because we don't want to use that for production, and we want to keep things the same between test and production.
>I should also mention that the admin gave us more space on that elastic pool just to immediately buy me some time to sort things out
That's the part I was trying to turn into metrics: knowing when I need to increase MAXSIZE for a database or a pool, based on the current allocated vs. MAXSIZE, and when I need to scale up (and how far) because the MAXSIZE has hit the limit for the number of vCores. Our Infrastructure Team developed some very complex PowerShell to do all that, but it was a lot of effort (including dynamically fetching the current storage limit for each quantity of vCores for each tier, because once we had an initial version working, Microsoft increased many of those limits). The security was also complicated to work with, as each pool uses different access credentials.