Your Azure SQL Database was fine, and now under load queries crawl, connections pile up, and requests time out. The database isn't broken — it is being throttled because it hit a resource ceiling. Here is how to confirm that and fix it properly.
Confirm You're Hitting the Ceiling
Azure SQL caps you on compute, measured in DTUs (or vCores in the vCore model). When you exhaust them, requests queue and slow down. Check whether you are pinned at the limit:
SELECT TOP 5 end_time, avg_cpu_percent, avg_data_io_percent, avg_log_write_percent FROM sys.dm_db_resource_stats ORDER BY end_time DESC;
If any of these sit near 100%, that resource is your bottleneck.
Cause 1: A Missing Index Forcing Scans
Often the tier is fine and a single bad query is burning all the IO with full table scans. Find it and add the index the optimizer is asking for:
SELECT * FROM sys.dm_db_missing_index_details;
Adding one well-chosen index frequently drops resource usage more than a tier upgrade would.
Cause 2: Genuinely Under-Provisioned
If usage is high across the board because your workload simply grew, scale the tier up. Azure SQL scales with almost no downtime:
az sql db update \ --resource-group my-rg --server my-server --name my-db \ --service-objective S3
Cause 3: No Connection Pooling
Each new connection is expensive. An app that opens and closes connections per request exhausts the connection limit and adds latency. Reuse a pool so a bounded set of connections is shared across requests.
Summary
Azure SQL throttling means you exhausted the compute your tier allows. Confirm it with sys.dm_db_resource_stats, then fix the actual cause: add the missing index if one bad query is scanning tables, scale the tier up if the workload genuinely outgrew it, and pool connections so you don't waste capacity on churn. Diagnose before you upgrade — an index is cheaper than a bigger tier, and often faster.