What's changed: Deepened DP-300 Chapter 1 (ja figures; comparison tables/scenarios/FAQ/traps/deep paragraphs in all sections)
1.2Service Tiers and Scaling
Understand Azure SQL service tiers—General Purpose, Business Critical, and Hyperscale—plus scaling via vCore/DTU, serverless, and elastic pools.
Even within Azure SQL, performance, availability, and cost vary greatly by service tier. Select and scale to match the workload.
1.2.1Differences between service tiers
- General Purpose: balanced; sufficient cost/performance for most workloads.
- Business Critical: high performance, low latency; local SSD, built-in availability replicas, read scale-out.
- Hyperscale: very large (up to 128 TB); fast backup/restore, separated storage and compute.
- Scaling: change vCore/DTU; serverless for intermittent workloads; elastic pools for many DBs.
Common on DP-300: low latency, high availability, read scale-out = Business Critical, very large + fast restore = Hyperscale, balanced = General Purpose, cost-optimal for intermittent = serverless, resource sharing across many DBs = elastic pool.
Serverless can auto-pause/resume by usage, lowering cost for intermittent or unpredictable workloads.
Service tiers map directly to availability architecture. General Purpose separates compute from remote storage (Azure Premium storage), recovering on node failure by reattaching to another node (cost-efficient). Business Critical runs an Always On availability group where each replica has local SSD, enabling low latency, automatic failover, and read scale-out (route to a read-only replica with ApplicationIntent=ReadOnly). Hyperscale distributes storage via page servers, and by separating it from compute achieves size-independent fast backup/restore and many read replicas. Raise availability with zone redundancy across AZs, optimize intermittent workloads with serverless (auto pause/resume, per-second billing), and share capacity for many off-peak DBs with elastic pools. Scale via changing vCore/service tier (often online and brief) or offload reads to replicas. Hyperscale previously could not be reverted to other tiers, but migrating Hyperscale to General Purpose is now supported; Business Critical replicas are central to its SLA/performance.
| Tier | Storage | Availability/perf | Best for |
|---|---|---|---|
| General Purpose | Remote (separated) | Standard, cost-efficient | Most business DBs |
| Business Critical | Local SSD | Low latency, auto-FO, read scale-out | Mission-critical |
| Hyperscale | Page servers (distributed) | Very large, fast restore | Tens of TB, growing |
Scenario: a payments DB needs low latency and automatic failover, and reporting reads should be offloaded from production. → Choose Business Critical, route read queries to the read-only replica with ApplicationIntent=ReadOnly, and enable zone redundancy for AZ failures. For very large size with fast restore, consider Hyperscale.
FAQ: Q. Which tiers offer read scale-out? → A. Business Critical and Hyperscale; route to a read-only replica with ApplicationIntent=ReadOnly. Q. Which workloads suit serverless? → A. Intermittent/unpredictable ones; for steady high load, provisioned is often more stable and cheaper.
Trap: “General Purpose supports read scale-out (read-only replicas)” is wrong—read scale-out is Business Critical / Hyperscale. Also “serverless is always cheapest” is wrong—for steady high load, provisioned is often cheaper. Note that migrating Hyperscale to General Purpose is now supported (it was not previously).
1.2.2Section summary
- Tiers = General Purpose / Business Critical / Hyperscale
- Scaling = vCore/DTU, serverless, elastic pools
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which service tier fits mission-critical DBs needing low latency, high availability, and read scale-out?
Q2. Which service tier fits very large DBs (tens of TB) needing fast backup/restore?
Q3. You want to lower cost for intermittent, unpredictable workloads. Which fits?