Azure SQL Database pricing: a practical estimate (compute, storage, backups, transfer)
Managed database cost is usually "capacity + data". The safest estimate breaks the bill into clear line items you can validate: compute, data storage, backup/retention, and data transfer. This guide gives you a workflow that works even when you don't know the exact SKU yet.
0) Choose a purchase model (so you model the right unit)
Azure SQL can be expressed in different purchase models (for example, vCore vs DTU) and deployment shapes (single database vs pool). The estimate workflow is the same, but your "compute unit" differs.
- Single database: model one workload with one baseline.
- Pool: model the sum of workloads and the peak overlap (pools are about smoothing peaks).
- Serverless patterns: model baseline + peak separately (autoscale is not free if the peak is frequent).
1) Compute baseline (capacity)
Pick an initial baseline based on expected concurrency and query complexity, then plan headroom. For spiky workloads, keep a separate peak scenario rather than assuming peak 24/7.
- Baseline: typical business hours load and steady queries.
- Peak: batch jobs, report generation, deploy windows, incident retries.
- If you do not have data, bracket with two baselines (conservative vs aggressive) and validate once you have metrics.
Tool: Compute instance cost (use it as a generic monthly capacity price model).
2) Storage (GB-month) and growth
Storage estimation is about the average size across the month, not just today's size. If your dataset grows, average GB is larger than the starting GB.
Tool: Database storage growth.
- Separate data from logs/temp if your workload has heavy write churn.
- Track growth drivers: retention tables, event logs, audit trails, large indexes.
3) Backups and retention (often the quiet multiplier)
Backup storage is usually not the same as primary data storage. It scales with retention windows and with how quickly data changes (churn). If you keep long-term retention, model it as its own line item.
- PITR retention: short/medium window for operational recovery.
- Long-term retention: compliance-driven; keep volume controlled.
- If your workload is append-heavy, backup growth can track data growth closely.
4) Data transfer (validate boundaries)
Database traffic itself is often small bytes compared to web traffic, but data movement can matter when you do exports, analytics, or cross-region access. Model transfer separately so you don't miss a high-volume ETL path.
Tools: Data egress, Cross-region transfer.
5) Observability (logs/metrics are separate bills)
Production databases often generate logs and metrics that are billed by ingestion, retention, and scan/query. Keep those as explicit line items until you have real usage.
Tools: Log ingestion, Tiered log storage, Log scan, Metrics time series.
Worked estimate template (copy/paste)
- Compute = baseline capacity + peak capacity scenario (if applicable)
- Primary storage GB-month = average GB across the month (include growth)
- Backup retention = PITR days + any long-term retention policy
- Transfer GB/month = exports + cross-region access + other billed legs
- Observability = logs ingestion + retention + scans + metrics series
Common pitfalls
- Sizing from averages only (peak concurrency and IO bursts decide the tier).
- Modeling storage as "today's GB" and ignoring growth (GB-month is about average).
- Forgetting backup retention and long-term retention policies.
- Ignoring export/ETL traffic that creates real egress or cross-region transfer.
- Letting observability grow unbounded (logs retention drift is common).
How to validate
- Validate peak CPU/IO usage and slow-path queries (p95 matters).
- Validate storage growth drivers (tables, indexes, retention policies).
- Validate backup retention windows and whether long-term retention is enabled.
- Validate network paths (private vs public, cross-region) and which are billed.