The instinct when Azure SQL feels slow is to reach for the compute tier slider — scale up, see if it helps, repeat. That approach works, in the sense that more compute usually papers over a performance problem. It also means you're paying enterprise prices to avoid diagnosing a problem that might cost nothing to fix.
Before changing the tier, there's a specific order worth working through — because each step rules out a category of problem the next step would otherwise have to account for.
1. Start With Query Store, Not the Query You Think Is Slow
Query Store is enabled by default in Azure SQL Database and captures execution statistics and plan history automatically — which means the data you need is usually already there. The "Top Resource Consuming Queries" view sorted by total duration, not average duration, is the right starting point: a query that runs in 50ms but executes 200,000 times a day often matters more than a query that runs once and takes 4 seconds. Resist the urge to start with the query a developer flagged as slow; let the data identify the actual top consumer first.
2. Read Wait Statistics Before Touching Indexes
Wait statistics tell you what SQL Server is actually waiting on, which determines whether an index will even help. High PAGEIOLATCH waits point to I/O pressure or memory pressure forcing pages out of buffer cache. High SOS_SCHEDULER_YIELD points to CPU pressure. High LCK_M_* waits point to blocking, not slow queries at all — and no amount of indexing fixes a blocking problem. Query Store now surfaces wait stats per query directly, which removes the need to correlate separately captured DMV snapshots against query IDs by hand.
3. Check tempdb Contention Separately
Azure SQL Database workloads that lean heavily on temp tables, table variables, or sort/hash operations can hit tempdb contention that looks like generic slowness in every other metric. PAGELATCH waits (distinct from PAGEIOLATCH) on tempdb system pages are the signal — and the fix is usually query-pattern changes or memory-grant tuning, not a bigger compute tier, since tempdb contention often gets worse, not better, with more parallelism.
4. Let Automatic Tuning Show Its Work, Then Verify It
Azure SQL Database's automatic tuning will create and drop indexes based on observed workload patterns, and verify the impact before keeping a change. It's genuinely useful — but it tunes for the workload it has observed, not the workload you're about to run after a product launch or a new reporting feature ships. Treat automatic tuning's recommendations as a starting point to review, not a replacement for understanding why a query is slow.
5. Right-Size the Compute Tier Last, With Data
Once query patterns, indexing, and tempdb contention are addressed, compute tier sizing becomes a much smaller decision — and one you can make with actual DTU/vCore utilization data instead of guesswork. Azure SQL's built-in sizing recommendations (and the Intelligent Insights feature, where available) compare observed resource consumption against your current tier, which is a far more defensible basis for a scaling decision than "it felt slow during the demo."
The Pattern Behind All Five Steps
Each step rules out a category of problem before the next step has to account for it. Skip straight to scaling compute, and you'll mask — not fix — query-pattern problems, tempdb contention, and blocking issues that will resurface the next time load increases. Working the list in order costs an afternoon. Skipping it costs a recurring line item on the Azure bill.
If you want this analysis run against your actual environment, request a SQL Server Health Check.