Azure SQL Memory shows memory and related resource information for a selected Azure SQL database. Use it when workload latency suggests memory pressure or when service tier capacity is under review.
Workflow
- Open the Azure SQL database.
- Select Memory.
- Review current and historical memory indicators.
- Compare memory pressure with Activity, Queries, and Waits.
- Check Elastic Pools if the database is pool-hosted.
How To Review Azure SQL Memory
Azure SQL memory evidence should be interpreted with service tier and workload context. A database on a lower tier or in a busy elastic pool may show pressure because it is sharing limited resources, while another database may show pressure because one query reads too much data or uses inefficient plans.
Start by checking whether the symptom affects one statement, one database, or several databases in the same pool. If one query dominates, use Azure SQL Queries and Azure SQL Query Store. If many sessions slow down together, compare memory evidence with Azure SQL Waits, Azure SQL Database Summary, and Azure SQL Elastic Pools.
Do not treat memory pressure as a reason to scale up immediately. Query tuning, indexing, plan regression investigation, or workload scheduling may solve the problem without increasing Azure cost.
Azure SQL Memory FAQ
Should I scale the database when memory pressure appears?
Not automatically. First confirm whether the pressure comes from query plans, indexes, pool contention, or workload timing.
Why does elastic pool context matter?
Databases in a pool share resources. One noisy database can affect another database in the same pool.
What pages should I compare with memory?
Use Activity for live sessions, Queries and Query Store for SQL evidence, Waits for delay reasons, and Elastic Pools for shared capacity.