Azure SQL DB: per-database sizes ARE readable from master via sys.resource_stats — we report only the connected database #2643

Split out of #2640 at Erik's request. Raised by ZedZipDev, whose framing was right and whose suggestion is achievable: "maybe get db sizes but not file sizes? As for me it will be enough to see the db size."

I told them this was impossible. It is not.

On #2640 I wrote that "there is no connection on Azure SQL DB that can see them all, so 'all N databases' is not reachable from one entry — that is the platform, not the tool."

That is wrong, and I verified it is wrong against a live Azure SQL Database rather than reasoning about it again. Connected to master:

sys.databases       | 2 rows      -- every database on the logical server
sys.resource_stats  | 29 rows     -- per database, WITH SIZE

database_name | storage_in_megabytes | end_time
Erik          | 19090                | 2026-08-26 12:21:09
Erik          | 19074                | 2026-08-22 15:00:16

sys.resource_stats is a master-only view carrying storage_in_megabytes per database with about 14 days of history at five-minute grain. sys.databases in master enumerates the whole logical server. The reporter sees all 50 of their databases in the Database Resources tab for the same reason.

So per-database SIZE is reachable from one master connection. What is not reachable is per-FILE detail for a database you are not connected to — sys.database_files is database-scoped, which is why DatabaseSizeStatsCollector reads only the connected database (#1631 removed master from its path deliberately, because a database-level firewall rule makes master unopenable for that shape of login).

Both facts are true at once, and the collector took the wrong one as the whole story.

Suggested shape

On Azure SQL DB when the connection is to master, populate database sizes from sys.resource_stats — database name and total size, no file breakdown, which is exactly what the reporter asked for and what the platform offers.

• Keep the existing per-database path. A server entry pointed at a user database still gets true file-level detail from sys.database_files, which resource_stats cannot give. This is an ADDITIONAL source for the case that currently returns one database, not a replacement.
• The rows are not the same shape, and the grid must not pretend they are: a resource_stats row has a database and a size and no file name, no type, no used-vs-allocated split. Better a file_name of (whole database) and honest NULLs than a fabricated file.
• master is not always the connection. Gate on the connected database actually being master, not on IsAzureSqlDb — pointed at a user database the view is empty and the collector must not read that as "no databases".
• The history is a series, not a snapshot. Take the newest row per database; the older ones are a growth trend worth having later, and No bloat measurement for PostgreSQL: we collect the whole cause chain and none of the damage #2542's table-bloat work already has the shape for that.

Why this is worth doing rather than documenting

The current output for a master connection is two rows named master, on a grid headed "All Servers", for a server with fifty databases. #2642 made it explain itself, which stops it reading as a broken collector — but the reporter does not want an explanation, they want the sizes, and the platform will give them.