Explanation
Why the waste happens and who it affects.
Compute and storage are billed separately, and pausing the pool releases the compute nodes so DWU charges drop to zero while data stays intact and storage continues to be billed.
Many dedicated pools only do real work in narrow windows: a nightly load, business-hours reporting, or intermittent development and testing. When they are left online around the clock, nights and weekends are paid at the full DWU rate. Microsoft's cost-planning guidance for Synapse states that you can control dedicated SQL pool costs by pausing the resource when it isn't in use, for example during the night and on weekends, but dedicated pools have no automatic pause setting, so pausing has to be scheduled or scripted.
Billing model
The pricing dimensions that drive this cost.
Dedicated SQL pool charges are split between compute and storage.
- DWU compute
- Charged by the number of DWU blocks and hours running, at the pool's service level
- Paused pool
- No DWU compute charges while paused; running and queued operations are canceled when the pause starts
- Storage
- Charged per TB stored, including while the pool is paused
- Synapse Commit Units
- An optional one-year pre-purchase plan that discounts Synapse usage in exchange for an upfront commitment
How to detect
4 checks to find it in your estate.
- List dedicated SQL pools with status Online and review the Active queries (ActiveQueries), Connections and DWU used percentage (DWUUsedPercent) metrics by hour and weekday to find long windows with no activity
- Query sys.dm_pdw_exec_requests for the time of the last submitted request to confirm how long the pool has been idle
- Flag development, test and proof-of-concept pools (by name, tag or resource group) that have no scheduled pause pipeline, Azure Automation runbook or Azure Function
- Compare dedicated SQL pool compute cost in Cost Management with the hours the pool actually serves loads or queries
How to fix
5 ways to remove the waste.
- Pause pools outside their usage windows with a scheduled Synapse pipeline that calls the sqlPools pause and resume REST APIs, or with Azure PowerShell (Suspend-AzSynapseSqlPool) in an Azure Automation runbook
- Build the pause step into the end of batch load pipelines so the pool pauses as soon as the load finishes, and resume it at the start of the next run
- Let in-flight transactions finish before pausing, because pausing cancels running and queued operations and long transactions must roll back first
- Where the pool must stay reachable, scale it down to the smallest service level that meets off-peak needs instead of pausing, as Microsoft recommends
- For pools with sporadic ad hoc queries, evaluate serverless SQL pool, which is billed per TB of data processed, or migration to Microsoft Fabric Data Warehouse
Documentation
Vendor references for pricing and configuration.
- Plan to manage costs for Azure Synapse Analyticslearn.microsoft.com
- Manage compute resources for dedicated SQL poollearn.microsoft.com
- How to pause and resume dedicated SQL pools with Synapse Pipelineslearn.microsoft.com
- Monitoring data reference for Azure Synapse Analyticslearn.microsoft.com
- Pricing - Azure Synapse Analyticsazure.microsoft.com