The DP-300 exam asks which service tier fits a given workload — not just what the tiers are called, but what tradeoffs each one carries. From the purchase model (DTU vs vCore) to the compute tier (Provisioned vs Serverless) and Elastic Pool, every option has a reason to exist.
DTU vs vCore: Bundle Package vs Build Your Own
Think of DTU as a bundle package at a grocery store — CPU, memory, and I/O are wrapped into one number. Simple pricing, predictable billing, no need to tune individual knobs. The three service tiers in the DTU model are Basic, Standard, and Premium, scaling up in bundled resources as the number goes higher.
vCore is the opposite: pick your CPU core count, memory, and storage separately. This granularity lets you say "I need more cores but less storage," which a DTU package cannot accommodate. You can also bring your existing SQL Server licenses via Azure Hybrid Benefit to cut costs — a significant advantage for organizations migrating from on-premises SQL Server. All three vCore service tiers — General Purpose, Business Critical, and Hyperscale — sit within the vCore model.
The key exam signal: if the scenario mentions Azure Hybrid Benefit or independent resource control, the answer is vCore. If it mentions simple, predictable billing, think DTU.
General Purpose: The All-Purpose Warehouse
When a logistics company needs a new warehouse for general cargo — no refrigeration, no hazardous materials handling — they rent a standard space. Good enough capacity, reasonable cost. General Purpose is that standard warehouse for Azure SQL Database.
General Purpose uses Azure Premium Storage (remote SSD) and supports up to 8,000 IOPS. High availability is handled through storage replication and automatic failover, though the failover process can take 20 to 30 seconds. It is the default starting point for most OLTP and reporting workloads.
One thing to note: General Purpose does not support In-Memory OLTP. For workloads requiring very high transaction throughput — think financial trading systems — Business Critical is the right fit instead. General Purpose suits development databases and moderately loaded production applications where cost control matters more than peak performance.
Business Critical: Local SSD and AlwaysOn
An airport control tower cannot afford a slow network connection. Radar data and flight movements need instant responses, always. Business Critical is that always-on, low-latency tier for Azure SQL Database.
Business Critical stores data on local SSD rather than remote storage, which means lower latency and significantly higher IOPS compared to General Purpose. Under the hood, it runs a four-node AlwaysOn Availability Group (AG) cluster. One of those secondary replicas is available as a read-only endpoint — a feature called Read Scale-Out.
Read Scale-Out comes at no additional cost. Routing reporting queries to the secondary can meaningfully reduce pressure on the primary, without paying for a separate read replica. In-Memory OLTP is also supported on Business Critical. When a workload needs high transaction throughput, low read latency, and strong availability guarantees, Business Critical is the answer.
Hyperscale: Walls That Expand on Their Own
Traditional databases are like fixed-size warehouses: when you fill them up, you have to move. Hyperscale tears down that ceiling. Storage scales automatically up to 100 TB as data grows, with no manual intervention.
Hyperscale uses a unique architecture built around Page Servers that manage storage independently from the compute layer. Scaling compute up or down completes in minutes rather than hours. Backups are snapshot-based, which means backup time does not grow proportionally with data size. Restore from snapshot is also fast regardless of database size.
The critical constraint: once a database is migrated to Hyperscale, it cannot be downgraded to General Purpose or Business Critical. That is a one-way door. Choose Hyperscale only when the data volume genuinely demands it — petabyte-scale datasets or workloads requiring instant snapshot-based recovery.
!Azure SQL service tiers
Serverless vs Provisioned: Pay for What You Use
Some offices run the air conditioning around the clock; others use a smart thermostat that turns it off when the building is empty and wakes it up when someone arrives. Provisioned compute is the always-on model. Serverless is the smart thermostat.
Serverless is available only within the General Purpose vCore tier. It supports auto-pause — the database suspends after a configurable idle period — and auto-resume — it wakes up automatically when a connection arrives. Billing is per second of activity, so an idle development database costs almost nothing overnight.
The downside is cold start latency. When the database resumes from a paused state, the first request may wait anywhere from a few seconds to over a minute depending on data cache warmth. For production workloads that need consistent response times, Provisioned is the right choice. Serverless is ideal for dev/test environments or internal tools with unpredictable usage patterns.
Elastic Pool: The Shared Swimming Pool
A hotel pool serves dozens of guests without each guest needing their own pool. It works because not everyone swims at the same time. Elastic Pool applies the same logic to databases.
An Elastic Pool lets multiple databases share a single pool of resources — either DTU-based or vCore-based. Each database can define a minimum guaranteed allocation and a maximum cap, preventing any single tenant from consuming the entire pool. SaaS applications where each customer has their own database are the classic use case: instead of provisioning full dedicated resources for each tenant, all tenants share one pool and each gets what it needs when it needs it.
The efficiency gain is real when tenant workloads peak at different times. Elastic Pool is most effective for many small databases with variable, non-overlapping peak usage.
Pitfalls When Choosing a Tier
When packing for a trip, assuming you can buy everything at the destination is a gamble that often does not pay off. Azure SQL Database has similar one-way decisions that are expensive to reverse after deployment.
The most critical pitfall is that migrating to Hyperscale is a one-way operation. There is no path back to General Purpose or Business Critical once you cross that boundary. Similarly, Serverless and geo-replication cannot be used together. If you choose Serverless for a production database and later need disaster recovery via geo-replication, you will have to switch to Provisioned first.
Migration from DTU to vCore is supported, but the reverse — vCore to DTU — is not. Business Critical's Read Scale-Out is free, but General Purpose does not have it. These constraints mean that tier selection at deployment time has long-term consequences — the right choice upfront saves significant rework later.
Exam Key Takeaways
"Independent CPU and storage control" -- vCore model "Azure Hybrid Benefit license portability" -- vCore model "Simple bundled pricing, Basic/Standard/Premium" -- DTU model "Petabyte-scale data, instant scale, snapshot restore" -- Hyperscale "Downgrade from Hyperscale" -- not supported (one-way migration) "Local SSD, AlwaysOn AG 4 nodes, In-Memory OLTP" -- Business Critical "Read-only replica at no extra cost" -- Business Critical Read Scale-Out "auto-pause / auto-resume, per-second billing" -- Serverless "Serverless + geo-replication" -- not compatible "Multiple databases sharing a resource pool, SaaS tenants" -- Elastic Pool "Remote Premium Storage, general-purpose OLTP" -- General Purpose
DTU = simple bundle, vCore = granular control; GP = general, BC = high performance + local SSD, Hyperscale = massive scale (one-way)