A monthly price on a configuration page is only the opening bid. Cloud database cost depends on when compute runs, how data grows, how long backups stay, and where bytes travel. Build the estimate from your current workload before selecting a tier.
Choose the Billing Model Behind Cloud Database Cost
Azure SQL offerings include provisioned and serverless compute choices, and pricing varies by region, tier, licensing option, and reservation. Start with the exact candidate service and its billing units. A SQL Server VM also has guest and license costs. Do not compare a managed database quote with a VM quote that omits SQL licensing or backup storage.
I list assumptions on one page: region, service, tier, vCores, hours, storage, retention, and network path. Prices change. The measured workload and the assumptions are more durable than a copied price figure.
Measure CPU Over a Real Cycle
Collect CPU utilization and query CPU across normal and peak periods. Averages hide month-end reports and nightly loads. If a current server is overprovisioned, matching its core count in the cloud will overstate demand. If it is saturated, copying its size will understate it. Tune obvious waste before estimating the target.
I use a week or a full business cycle when the workload has scheduled peaks. The query below shows visible SQL Server capacity, not usage. Combine it with Windows and Query Store history.
SELECT cpu_count, scheduler_count,
sqlserver_start_time
FROM sys.dm_os_sys_info;
SELECT name, value_in_use
FROM sys.configurations
WHERE name = 'max degree of parallelism';Translate Activity Into vCore Demand
vCore-based tiers charge for provisioned capacity or, in serverless options, compute usage subject to minimums and auto-pause rules. Estimate the number of vCores needed at peak and the hours they remain active. A busy application with constant connections can keep serverless online, reducing the expected savings.
A test migration gives stronger evidence than a spreadsheet alone. Run representative queries on a candidate tier and inspect CPU, data I/O, and log I/O limits. I present a range rather than a false precise number from one CPU graph.
Count Data and Index Storage
Current data files include free space inside files, indexes, and cold history. Cloud storage needs the active data and expected growth, plus service-specific storage behavior. Index cleanup or retention can lower the target size, but do not remove useful structures solely to improve a quote. Forecast several growth scenarios.
This query lists file allocation in the current database. Add used-space data and a growth history before turning it into a purchase estimate.
SELECT name, type_desc,
size * 8.0 / 1024 AS allocated_mb,
growth, is_percent_growth
FROM sys.database_files
ORDER BY file_id;
Include Backup Retention in Cloud Database Cost
Automated backup storage and long-term retention can contribute to the bill, depending on service and included allowances. Retention policy should come from recovery and compliance needs, not the cheapest pricing row. Estimate full, differential, and log data volume where that model applies, and test restore time.
I ask how many older recovery points the business truly needs. Retaining everything forever sounds safe until nobody can explain or test the archive. A clear policy saves money and improves recoverability.
Estimate Network Movement
Network egress can matter when applications, reports, or replicas move large amounts of data across regions or out of Azure. Ingress and traffic within a chosen topology have different price rules. Draw the actual data path before estimating. A chatty application left on premises can add latency as well as network cost.
I measure bytes returned by major reports and bulk exports, then account for frequency. Query Store reads are not network egress. The result set size and destination are what matter for this line. Confirm the current regional pricing terms in the official calculator.
Include Operations and Resilience
High availability, geo-replication, monitoring, support, and security services can add cost. A readable secondary doing reports is a separate workload target, not a free copy. A VM requires patching and SQL backups that a managed service handles differently. Compare total cloud database cost, including the team work that remains.
I do not hide a required disaster recovery region to make the cloud proposal look cheaper. The comparison must satisfy the same recovery objective on both sides. Otherwise it is comparing different products with the same database name.
Build Three Cloud Database Cost Scenarios
Make a low, expected, and high case for compute hours, storage growth, backup retention, and egress. Include an unexpected peak and a failed auto-pause assumption. Use current Azure price inputs for each case. A range is more honest than an exact monthly promise before the application has run in the target service.
Query Store can identify resource-heavy queries that affect sizing. This example ranks total CPU over retained intervals in the current database. Check capture policy and interval coverage before using it.
SELECT TOP (10) q.query_id,
SUM(rs.avg_cpu_time * rs.count_executions)
/ 1000000.0 AS total_cpu_seconds
FROM sys.query_store_query AS q
JOIN sys.query_store_plan AS p ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id = p.plan_id
GROUP BY q.query_id
ORDER BY total_cpu_seconds DESC;Validate After a Pilot
Run a representative pilot and compare its actual bill and workload metrics with the estimate. Note the tier, active hours, storage, backups, and network route. If a metric differs, update the model rather than explaining it away. Set alerts for spend and resource saturation before production cutover.
Cloud database cost is an operating measurement, not a one-time quote. Keep the model beside the service and review it as traffic and features change. The most useful estimate is one that can be corrected by evidence.
Estimate at least one quiet period and one peak period. A constant compute tier and an auto-scaling option can have different economics depending on idle time, memory needs, and response targets. Storage, backup retention, network transfer, and high availability can change the total more than a small compute difference. List each assumption next to its cost line.
I use a pilot to replace assumptions with measured utilization. The pilot needs representative queries and concurrency, not just a database copy with one user. Compare actual CPU, I/O, waits, and response behavior with the budget model. If the pilot differs, revise the model before committing to a larger move. A precise spreadsheet built on a guessed workload is still a guess.
Which assumption in your cost estimate is based on measured workload, and which still needs a pilot?
Related reading on this blog: Optimizing Cloud Costs with Diagnostic Tools: A Business Imperative and SQL Server Monitoring Across Cloud, Hybrid, and On-Prem.
A cloud price is not a workload estimate, it is a rate applied to measured demand.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
