3.2 Azure SQL Database Pricing & Performance Tiers
Key Takeaways
- Azure SQL Database has two purchasing models: **DTU-based** (Basic, Standard, Premium) bundles compute, memory, and I/O, while **vCore-based** (General Purpose, Business Critical, Hyperscale) lets you scale CPU and storage independently.
- The **vCore** model supports both **provisioned** and **serverless** compute; serverless auto-pauses inactive databases and resumes them on the next connection, billing per-second when active.
- **Business Critical** uses local SSD and Always On replicas for the lowest latency and highest availability; **General Purpose** uses remote storage for cost-balanced workloads.
- **Hyperscale** offers near-infinite storage up to 100 TB, fast database copies, and rapid scale-out read replicas, designed for very large OLTP databases.
- **Elastic pools** share a fixed pool of DTUs or vCores across many databases with varying usage patterns, lowering cost compared with provisioning each database for peak load.
Two Purchasing Models
Quick Answer: Azure SQL Database has two purchasing models. DTU-based uses pre-packaged tiers — Basic, Standard, and Premium — where each tier bundles a fixed amount of compute, memory, and I/O. vCore-based lets you choose CPU count, memory, and storage independently and select a service tier of General Purpose, Business Critical, or Hyperscale. Only the vCore model offers serverless compute and the Azure Hybrid Benefit.
DTU-Based Model
The Database Transaction Unit (DTU) is a blended measure of CPU, memory, and I/O. Higher DTUs mean more resources. The model is simple — you pick a tier and a DTU count and Microsoft does the sizing for you.
| DTU Tier | Use Case | Storage Type |
|---|---|---|
| Basic | Small, low-traffic databases for dev/test | Standard storage |
| Standard | Moderate workloads, web apps, small line-of-business systems | Standard storage |
| Premium | I/O-intensive transactional workloads | Local SSD |
DTU is best for small or predictable workloads where you do not need to scale CPU and storage independently.
vCore-Based Model
The virtual core (vCore) model maps directly to hardware: you choose a hardware generation, number of vCores, memory, and storage size. It supports the Azure Hybrid Benefit, which lets you apply existing on-premises SQL Server licenses with Software Assurance to lower the Azure cost.
| vCore Service Tier | Storage | Availability | Best For |
|---|---|---|---|
| General Purpose | Remote Azure Premium storage | 99.99% | Cost-balanced production workloads |
| Business Critical | Local SSD with Always On replicas | Up to 99.995% with zone redundancy | Low-latency OLTP, mission-critical apps |
| Hyperscale | Distributed page-server architecture | Multiple read replicas | Very large databases up to 100 TB |
Hyperscale decouples compute from storage using a tier of page servers, which is why it can scale storage to about 100 terabytes and provision a new read replica in minutes. It is the recommended tier when a database is too large or grows too fast for General Purpose or Business Critical.
Serverless Compute
Serverless is a compute option on the vCore General Purpose tier. You set a minimum and maximum vCore range, and Azure automatically scales compute within that range. If the database is idle past an auto-pause delay (default one hour, minimum 60 minutes), the database pauses and you pay only for storage. The next connection resumes it automatically, usually within seconds.
Use serverless for development databases, single-tenant SaaS workloads with idle periods, or applications with unpredictable usage. Use provisioned compute when you need predictable, sustained performance.
Elastic Pools
An elastic pool is a shared bucket of DTUs or vCores that many databases can draw from. Instead of paying for the peak load of each database individually, you size the pool for the aggregate workload. Pools are ideal for SaaS providers with many tenant databases that each have low average usage but occasional spikes — typical of multi-tenant applications.
Choosing a Tier
- Dev/test or tiny app: Basic DTU or General Purpose serverless with a low max vCore.
- Steady production OLTP: General Purpose vCore (provisioned).
- Latency-sensitive, mission-critical: Business Critical with zone redundancy.
- Very large, growing OLTP: Hyperscale.
- Many small databases with bursty usage: elastic pool.
Service Level Agreements
The baseline SLA for Azure SQL Database is 99.99% availability. Business Critical with zone redundancy raises this to up to 99.995%. Hyperscale provides its own resiliency through replicated page servers. SLAs apply per database, not per region — pairing with active geo-replication or auto-failover groups is what protects against regional outages.
Hardware Configurations in the vCore Model
Within the vCore model you also pick a hardware configuration (sometimes called a compute series). The common options are standard-series (Gen5) for balanced general workloads, premium-series and premium-series memory optimized for higher memory-to-core ratios, and earlier Fsv2/M-series families on some tiers. The hardware choice sets the ratio of memory and I/O per vCore, which matters for memory-hungry workloads. For DP-900 you do not need to memorize each family — only to recognize that vCore lets you tune CPU, memory, and hardware generation independently, which the DTU model hides.
DTU vs vCore: How to Read a Question
| Signal in the question | Likely answer |
|---|---|
| "Simple, bundled, pick-a-number sizing" | DTU model |
| "Independently scale CPU and storage" | vCore model |
| "Apply existing SQL Server licenses (Hybrid Benefit)" | vCore model |
| "Pause compute when idle" | vCore serverless |
| "Grow beyond a few TB / fast read replicas" | vCore Hyperscale |
| "Lowest latency, local SSD, mission critical" | vCore Business Critical |
Reading Replicas and Scale-Out
Business Critical and Hyperscale both support read scale-out: a read-only replica answers reporting queries so they do not compete with the primary's writes. In Business Critical this uses one of the built-in high-availability replicas at no extra charge (you connect with ApplicationIntent=ReadOnly). Hyperscale can add several named replicas for heavy read fan-out. General Purpose has no built-in readable replica by default. This is a frequent exam nuance: if a scenario wants to offload reporting reads without geo-replication, the answer is Business Critical or Hyperscale read scale-out, not General Purpose.
Storage and Backups Across Tiers
All tiers include automated backups, but the maximum database size differs sharply: Basic/Standard DTU and General Purpose vCore cap in the low single-digit-TB range, Business Critical somewhat higher, and Hyperscale up to about 100 TB. When a question describes a database that has outgrown the other tiers' size limits, Hyperscale is almost always the intended answer because of its decoupled page-server storage. Remember that compute and storage bill separately in the vCore model, and that pausing serverless or a Hyperscale-style pause stops the compute charge while storage continues to bill.
A SaaS provider hosts 50 customer databases. Each customer rarely uses the database at the same time, and average load per database is low. Which Azure SQL Database option minimizes cost while still meeting bursty demand?
Which Azure SQL Database service tier is designed for databases that can grow up to about 100 TB and need rapid scale-out of read replicas?