I just watched a load test hit that issue, the developers cranked up the traffic until the response times were measured in minutes. At that point Azure SQL started throwing errors related to too many concurrent queries.
Compared to just locking up or timing out, it's probably better.
See: https://docs.microsoft.com/en-us/azure/azure-sql/database/re...
And: https://docs.microsoft.com/en-us/azure/azure-sql/database/re...
E.g.: the 4-CPU pool has only 210 Max concurrent workers per pool, but if you think about it, that's over 50 queries running at once per CPU core, which is nuts!
Ps: if you’re working on a production load system, and has decent traffic, lean towards premium/business critical tiers for true HA
AWS tells you when your maintenance window for an RDS instance will be and you can delay/reschedule as needed.
I wouldn't consider a maintenance window as "downtime". That 99.95 applies to all the time outside the window.
“Downtime as part of Scheduled Maintenance will not be counted towards any Downtime Period.” - https://cloud.google.com/sql/sla
I’ve never seen an SLO document for CloudSQL though so the SLOs may be slightly higher internally?