Recommend a Database Service Tier and Compute Tier — Lesson

Choosing a service tier and compute tier for Azure SQL Database is the point in your architecture where you translate workload behaviour into a monthly bill. The exam tests whether you can map a written business requirement — RTO targets, peak IOPS, burstiness, licence portfolio — to the correct combination of purchasing model (DTU vs vCore), service tier (General Purpose / Business Critical / Hyperscale), compute tier (Provisioned vs Serverless), and hardware generation.

This lesson treats sizing as a decision tree. You already know which engine to use from the preceding LO; here we refine the answer by selecting the right SKU inside Azure SQL Database. Worked examples use Azure pricing ratios and published platform limits rather than dollar figures, since prices drift but ratios are stable.

Why This Matters

A single SKU decision can shift annual database cost by $5\times$ for the same workload. A team that picks Business Critical when General Purpose would suffice overpays by roughly $2.$5\times$$ for redundancy they never exercise. A team that picks General Purpose for an OLTP system whose log throughput peaks at 60 MB/s discovers after go-live that General Purpose caps log throughput at 30 MB/s on the vCore counts they chose — transactions queue, and end-users feel it. Neither decision is caught by a "will it run?" test; both show up in the invoice and the on-call rotation.

For the AZ-305 exam, tier selection is one of the three most frequently tested design decisions in the relational-data unit. Scenarios usually give you workload characteristics (OLTP vs analytical, peak concurrency, IOPS hints, idle-time patterns) plus constraints (budget ceiling, SLA target, existing SQL Server licences) and ask you to pick the smallest SKU that still meets the requirements. The smallest part matters — the exam rewards cost-aware architects, not defensive over-provisioners.

Prerequisites

• Recommend a relational data storage solution: you've already selected Azure SQL Database (PaaS, single database or elastic pool). Self-check: can you name two scenarios where SQL Managed Instance is correct instead?
• Transaction log mechanics: familiarity with write-ahead logging and how commit latency depends on log-flush performance. Self-check: why does Business Critical use local SSD for the log?
• SQL Server licensing basics: core-based licensing vs per-CAL, Software Assurance. Self-check: what does Azure Hybrid Benefit actually let you stop paying for?
• Azure subscription and pricing fundamentals: you know what a reservation is, what a region is, and that prices vary by region. Self-check: is a 1-year reservation always cheaper than pay-as-you-go?
• Basic IOPS / throughput vocabulary: you can read a workload description and spot whether IOPS, log throughput, or in-memory OLTP is the binding constraint. Self-check: if a benchmark shows 120 MB/s sustained log writes, can General Purpose cope?

Learning Objectives

By the end of this lesson you will be able to:

1. Compare the DTU and vCore purchasing models and recommend the correct one from workload requirements.
2. Evaluate the three vCore service tiers (General Purpose, Business Critical, Hyperscale) against workload, HA, and storage-size constraints and select the smallest tier that meets the scenario.
3. Analyse a workload's burstiness and idle-time pattern to recommend Provisioned vs Serverless compute for Azure SQL Database.
4. Design hardware configuration choices — Gen5, Premium-series, M-series — from memory-per-core and workload-size constraints.
5. Calculate the effective vCore cost after applying Azure Hybrid Benefit and reservations, and justify the savings to a budget stakeholder.
6. Diagnose mis-sized deployments post go-live from metric signals (log-throughput saturation, CPU starvation, cold-start latency) and recommend a corrective tier change.

Building Blocks

DTU — Analogy: a pre-mixed cocktail where the barista decides the CPU-to-IOPS-to-memory ratio. Formal: Database Transaction Unit, a bundled metric combining compute, memory, and I/O at fixed ratios. Why it matters: DTU is simple for small workloads and the only path that exposes the Basic tier (≤ 2 GB) — but it hides the dimensions you would tune separately in vCore.

vCore — Analogy: an à la carte menu where you pick cores, memory, storage, and service tier independently. Formal: Virtual Core-based purchasing model for Azure SQL Database and SQL Managed Instance. Each vCore corresponds to one logical CPU. Why it matters: vCore is the only purchasing model that exposes Business Critical, Hyperscale, Azure Hybrid Benefit, and reservations — so almost every production AZ-305 scenario lands in vCore.

Service tier — Analogy: seat class on an airline (Economy / Business / First). Formal: a named SKU family inside vCore that bundles a storage architecture, HA model, and performance envelope. The three tiers are General Purpose, Business Critical, and Hyperscale. Why it matters: service tier is the single biggest cost lever — a $2\times$ to $3\times$ jump between tiers is typical at matched vCore.

Compute tier — Analogy: flat-rate vs metered electricity. Formal: within a service tier, either Provisioned (fixed vCore, billed per hour) or Serverless (auto-scaling vCore, billed per second of actual usage with auto-pause). Why it matters: Serverless shines for bursty, low-duty-cycle workloads; Provisioned wins for steady workloads above roughly 25% duty cycle.

Gen5 hardware — Analogy: a generation of car engines — same chassis, updated internals. Formal: the default hardware generation for vCore, using Intel Xeon Platinum (8168/8272CL), providing $5.1 GB memory per vCore in General Purpose and Business Critical. Why it matters: Gen5 is the baseline — scenarios that name a special hardware (M-series, DC-series, Premium-series) are signalling either huge memory or confidential-compute needs.

Azure Hybrid Benefit (AHB) — Analogy: bring-your-own-wine to the restaurant — you pay only for the meal (compute + storage), not the corkage (licence). Formal: a licensing programme that lets customers with SQL Server Enterprise or Standard licences and active Software Assurance apply those licences to Azure vCores, paying the base rate instead of the licence-inclusive rate. Why it matters: AHB typically reduces vCore cost by 30–55%; scenarios that mention "existing SQL Server licences with SA" almost always expect AHB in the answer.

Log throughput ceiling — Analogy: the drain size of a kitchen sink — the pour rate does not matter once the drain saturates. Formal: the maximum transaction-log write rate the service tier supports at a given vCore count, capped at 30 MB/s for General Purpose single databases and 100 MB/s for Business Critical and Hyperscale. Why it matters: write-heavy OLTP workloads are usually log-bound before they are CPU-bound.

Memory-to-core ratio — Analogy: passengers per car — same cars, different seating arrangement. Formal: GB of RAM allocated per vCore. Gen5 provides $5.1 GB/vCore; M-series provides about 29 GB/vCore. Why it matters: in-memory OLTP, large plan caches, and columnstore benefit from a high memory-to-core ratio and may require Business Critical M-series to fit in memory.

Deep Dive

DTU vs vCore purchasing model

The DTU purchasing model bundles compute, memory, and IOPS into a single opaque unit. A Standard S3 database (100 DTU) gives you some CPU, some memory, and roughly 400 IOPS — you cannot separate them. DTU exposes four tiers: Basic, Standard, Premium, and the deprecated Premium RS. It is appropriate when the workload is small, steady, and simple, and the team does not want to reason about cores separately from IOPS.

The vCore model exposes each dimension independently: vCore count, memory (via hardware generation), storage size, storage type (remote SSD vs local SSD). It is the only model that supports Business Critical, Hyperscale, Azure Hybrid Benefit, reservations, and scale-to-zero serverless. For AZ-305, assume vCore unless the scenario is explicitly dev/test, under 10 GB, and on a tight budget ceiling in the $5–$15/month range.

[!TIP] A practical rule: 100 DTU ≈ 1 vCore General Purpose for CPU, but DTU includes more IOPS in the Standard tier than an equivalent single-vCore General Purpose SKU. When migrating from DTU to vCore, size with a benchmark, not a formula.

Service tiers — General Purpose, Business Critical, Hyperscale

These three tiers differ in storage architecture, HA model, maximum database size, and compute ceiling. Choose by identifying the binding constraint of the workload.

General Purpose uses remote page-blob storage with 5–10 ms latency per I/O, HA via Azure Service Fabric failover (cold-cache), and tops out at 4 TB per database. Log throughput caps at 30 MB/s. This is the default for line-of-business apps, reporting stores, and dev/test.

Business Critical uses local NVMe SSD (sub-millisecond latency), a 4-node Always-On Availability Group with synchronous replication, and supports in-memory OLTP. Log throughput caps at 100 MB/s. Read-scale to one replica is included. This is the choice when you need sub-5-minute RTO, in-memory OLTP, or the highest IOPS per vCore.

Hyperscale uses a custom storage architecture with page servers, a log service, and up to 4 named read replicas — data scales to 100 TB per database with near-constant backup time (snapshots are storage-layer, independent of size). It is built for databases too large for General Purpose ($> 4$ TB) or read-heavy workloads that benefit from multiple read replicas.

[!WARNING] Hyperscale does not support in-memory OLTP, SQL Server Audit writing to Azure Storage, or geo-restore in every region. If your workload depends on any of these, Business Critical is the correct tier even if the database is large.

Compute tier — Provisioned vs Serverless

Within General Purpose (and only within General Purpose), you can choose between Provisioned and Serverless compute. Provisioned bills you for a fixed vCore count 24/7. Serverless auto-scales vCore between a min and max, bills per second of actual vCore-usage, and auto-pauses the database after a configurable idle delay (minimum 1 hour).

Serverless is cheaper when duty cycle is below roughly 25% — that is, the database is idle or near-idle more than three-quarters of the time. The classic fit is dev/test, departmental apps used in business hours, and intermittent batch workloads. The gotcha is cold-start latency: after auto-pause, the first query waits 30–60 seconds for the database to resume.

[!NOTE] Business Critical and Hyperscale do not offer serverless compute. If the scenario names serverless, the service tier is implicitly General Purpose.

Hardware generation — Gen5, Premium-series, DC-series, M-series

Hardware generation inside a service tier determines memory-per-core and CPU model. Gen5 is the default for most vCore SKUs and provides $5.1 GB/vCore. Premium-series and Premium-series Memory-Optimised use Intel Ice Lake with higher GB/vCore — useful when the plan cache or buffer pool thrashes on Gen5. DC-series adds confidential-compute (Intel SGX) for Always Encrypted with secure enclaves. M-series on Business Critical targets workloads that need 29 GB/vCore and up to 128 vCores — think large in-memory OLTP or heavy columnstore.

[!IMPORTANT] Hardware generation is a first-class scaling axis. Memory pressure that cannot be solved by adding vCores on Gen5 (because the ratio is fixed) can often be solved by moving to Premium-series or M-series at fewer total vCores, at lower total cost.

Azure Hybrid Benefit and reservations

Azure Hybrid Benefit converts a vCore's licence-inclusive price to base price. Concretely, for Business Critical Gen5 the licence-inclusive rate is approximately $2.3\times$ the base rate — AHB removes that premium. AHB requires SQL Server Enterprise or Standard licences with active Software Assurance; you self-attest at deployment and recertify annually.

Reservations are independent of AHB. A 1-year reserved capacity commitment discounts the compute component by approximately 24%; a 3-year commitment discounts it by approximately 37%. AHB and reservations stack.

A left-to-right view of the serverless lifecycle helps visualise when cost accrues:

Worked Examples

Easy — Departmental expense-tracking app

Synthetic scenario (AZ-305 style). Contoso's finance team uses an expense-tracking app with about 40 active users in Central US, 9-to-5 on weekdays. The database is 18 GB. Peak CPU is about 25% on one core. Idle on weekends. Budget is tight.

Step 1 — Weekday-only, heavy idle → strong serverless candidate. Step 2 — Small DB (18 GB), no HA-critical SLA → General Purpose is sufficient. Step 3 — Peak CPU of 25% on 1 core → min $0.5 vCore, max 2 vCore covers peaks. Step 4 — Set autoPauseDelay to 60 minutes to catch overnight and weekend idle.

Answer: Azure SQL Database, General Purpose, Serverless, Gen5, min $0.5 / max 2 vCore, 50 GB storage.

[!NOTE] Key insight: the signal "idle on weekends" alone is worth approximately 28% savings vs provisioned — the weekend hours never bill.

Medium — Write-heavy IoT ingestion

Synthetic scenario (AZ-305 style). Fabrikam ingests telemetry from $50{,}000$ devices into a SQL database. Sustained write rate is 80 MB/s of transaction log during business hours, dropping to 20 MB/s overnight. Database size is 600 GB and growing by about 20 GB/month. Availability SLA is 99.99%.

Step 1 — Sustained log rate of 80 MB/s is above the General Purpose cap of 30 MB/s → General Purpose is disqualified. Step 2 — Size is 600 GB, growing — well under the 4 TB Business Critical cap for now. Hyperscale is possible but adds complexity (no in-memory OLTP) without a clear win. Step 3 — 99.99% SLA is met by Business Critical (published SLA 99.995%) with zone redundancy. Step 4 — Sustained writes above 25% duty cycle → provisioned, not serverless. Step 5 — Right-size vCore from log-throughput-per-core. Business Critical Gen5 supplies log throughput proportional to vCore up to the 100 MB/s cap; 16 vCore is a common choice for 80 MB/s sustained.

Answer: Azure SQL Database, Business Critical, Provisioned, Gen5, 16 vCore, zone-redundant, 1 TB storage reservation.

[!NOTE] Key insight: the binding constraint was log throughput, not CPU. The exam frequently uses sustained log-write rates as the trigger to eliminate General Purpose.

Hard — Reporting on a 40 TB database with bursty read-scale

Synthetic scenario (AZ-305 style). Tailwind Traders runs a retail-analytics workload. Database size is 40 TB today, projected to reach 65 TB in 18 months. The workload is 80% reads issued by about 400 concurrent analyst sessions during month-end close (3 days / month), with light read traffic otherwise. The team holds existing SQL Server Enterprise licences with SA.

Step 1 — 40 TB already, 65 TB projected → exceeds General Purpose and Business Critical caps (4 TB). Only Hyperscale fits. Step 2 — 80% reads, high concurrency during month-end → add 3 named read replicas to handle close, scale them down between months. Step 3 — Workload pattern (heavy bursts 3 days/month, quiet otherwise) is not a serverless candidate at Hyperscale — Hyperscale has no serverless tier today. Use provisioned with replica-level scale-down. Step 4 — SQL Server Enterprise + SA → apply Azure Hybrid Benefit to all vCores (primary + named replicas). Step 5 — Choose hardware: Gen5 is fine for most Hyperscale workloads; Premium-series only if plan-cache pressure is proven.

Answer: Azure SQL Database, Hyperscale, Provisioned, Gen5, primary at 16 vCore, 3 named read replicas (8 vCore each) scaled up for 3 days/month, AHB applied, 1-year reservation on the primary.

[!NOTE] Key insight: Hyperscale's independent named replicas let you pay for the burst only when it happens, without the primary carrying the cost. This is the Hyperscale equivalent of "serverless for the expensive part."

Visual Explanations

The decision tree below captures the default AZ-305 path from requirements to SKU.

Caption — SKU selection decision tree. The tree encodes the exam's question structure: size, then log throughput, then HA / in-memory needs, then burstiness. Walking from top to leaf gives the minimum SKU that meets the stated requirements.

Below, a spatial view of the Business Critical HA architecture — one primary and three secondaries across Availability Zones.

Caption — Business Critical zone-redundant HA. Synchronous replication to three secondaries; Secondary 3 doubles as the free read-scale replica.

Caption — Tier trade-off matrix. Read from left to right: cost rises with tier richness; Hyperscale is an outlier on size.

Caption — Hardware generation summary. Move between rows when memory ratio becomes the binding constraint.

Cost optimisation stacks two discounts. Applied together on a committed Business Critical workload, the combined saving is typically in the 55–65% range vs pay-as-you-go licence-inclusive pricing:

Common Mistakes

❌ Myth: Business Critical is the "safe default" for production workloads. ✅ Reality: General Purpose is correct for the majority of line-of-business apps; Business Critical is for workloads that need local-SSD latency, in-memory OLTP, or sub-30-second RTO. Why it's tricky: architects default-assume "production = premium" when the right default is "production = General Purpose zone-redundant", upgrading on a measurable need.

❌ Myth: Serverless is always cheaper than Provisioned. ✅ Reality: Serverless wins below approximately 25% duty cycle. Above that, the per-second pricing premium outweighs the idle savings and Provisioned is cheaper. Why it's tricky: teams read "pay for what you use" and assume that's universally cheaper — but the rate is higher, so a 40%-duty workload pays more on Serverless.

❌ Myth: Hyperscale is just "Business Critical but bigger." ✅ Reality: Hyperscale uses an entirely different storage architecture (page servers + log service), does not support in-memory OLTP, and has different backup/restore semantics. Why it's tricky: Hyperscale shares the Business Critical log-throughput ceiling and both tiers have sub-second IO — the similarities hide architectural differences that matter for certain workloads.

❌ Myth: DTU is always the wrong choice in production. ✅ Reality: DTU is fine for small, steady workloads where the team does not want to reason about cores and IOPS separately — especially the Basic tier for sub-2 GB databases. Why it's tricky: the exam leans vCore because most production scenarios need AHB or Business Critical / Hyperscale, which are vCore-only — but "DTU is deprecated" is factually wrong.

Practice Exercises

Exercise 1 🟢 A dev/test database for a small internal tool, 5 GB, accessed by 3 developers a few hours a week. Recommend a SKU.

▶💡 Hint

Size tiny, usage sparse — which compute tier is literally designed for this?

▶✅ Solution

Azure SQL Database, General Purpose, Serverless, Gen5, min $0.5 / max 1 vCore, 10 GB storage, autoPauseDelay 60 minutes. Alternative: DTU Basic at approximately 5 USD/month if even simpler is preferred.

Exercise 2 🟡 A retail checkout database handles 99% of traffic steadily during business hours. CPU averages 55% on 8 cores. Sustained log is 22 MB/s. Recommend a SKU.

▶💡 Hint

Duty cycle disqualifies serverless. Is the log rate above the General Purpose cap?

▶✅ Solution

Azure SQL Database, General Purpose, Provisioned, Gen5, 8 vCore, zone-redundant. Log is under 30 MB/s so General Purpose suffices; steady CPU disqualifies serverless.

Exercise 3 🟡 A healthcare SaaS needs in-memory OLTP for real-time de-duplication. Database is 300 GB. SLA 99.99%.

▶💡 Hint

In-memory OLTP is only supported on one service tier.

▶✅ Solution

Azure SQL Database, Business Critical, Provisioned, Gen5, vCore sized by benchmark (commonly 8–16), zone-redundant. Business Critical is the only tier that exposes in-memory OLTP.

Exercise 4 🔴 A SaaS platform has 800 customer databases, each 20–200 GB, with uncorrelated usage (some peak 9 am UTC, others 9 pm). Recommend an approach.

▶💡 Hint

Many small DBs with uncorrelated peaks suggests a sharing mechanism, not bigger individual SKUs.

▶✅ Solution

Azure SQL Database elastic pool, General Purpose, Provisioned, Gen5, sized to handle aggregate peak (about the 80th-percentile of combined usage). Pool eDTU or eVCore shares compute across the 800 databases so peaks can overlap without per-database over-provisioning. Consider two pools split by geography if peaks are highly regional.

Exercise 5 🔴 A firm has SQL Server Enterprise licences with Software Assurance covering 64 cores. They want to migrate a $1.5 TB, write-heavy OLTP system (70 MB/s sustained log). They ask you to minimise cost without reducing performance.

▶💡 Hint

Two levers apply here — one is licensing, one is commitment term.

▶✅ Solution

Azure SQL Database, Business Critical, Provisioned, Gen5, 16 vCore (covers 70 MB/s log), zone-redundant. Apply Azure Hybrid Benefit (uses 16 of their 64 Enterprise cores) plus a 3-year reserved capacity commitment on the compute. Combined savings typically 55–65% vs PAYG licence-inclusive pricing.

Exercise 6 🟢 Which tier does not support auto-pause?

▶💡 Hint

Auto-pause is a Serverless feature; which tiers have no Serverless option?

▶✅ Solution

Both Business Critical and Hyperscale — Serverless is a General Purpose-only compute tier today.

Exercise 7 🟡 A scenario states sustained log throughput of 45 MB/s. Which service tiers remain valid candidates?

▶💡 Hint

Recall the log-throughput ceilings per tier.

▶✅ Solution

Business Critical and Hyperscale only — General Purpose caps at 30 MB/s single-DB log throughput, which is below the 45 MB/s requirement.

Exercise 8 🔴 A team plans to use Azure SQL Database Hyperscale and asks whether they should also enable in-memory OLTP. How do you advise?

▶💡 Hint

Feature-parity table.

▶✅ Solution

In-memory OLTP is not supported on Hyperscale. Either move the in-memory workload to a separate Business Critical database or redesign to avoid it (for example, use non-clustered columnstore for read-heavy aggregation paths).

Summary & Concept Map

• Purchasing model comes first — vCore is the default; DTU only for tiny/simple workloads.
• Service tier is the cost lever: General Purpose ≪ Business Critical ≈ Hyperscale in price; pick the smallest that meets binding constraints (size, log rate, HA).
• Hyperscale is the answer above 4 TB; Business Critical is the answer for in-memory OLTP or sub-30-second RTO.
• Compute tier — Serverless below approximately 25% duty cycle, Provisioned above; Serverless only exists in General Purpose.
• Hardware — Gen5 by default; move to M-series or Premium-series Memory-Optimised when memory-per-core is binding.
• Azure Hybrid Benefit + reservations stack — apply both when licences and commitment align.
• Right-sizing is an ongoing activity — watch log throughput, CPU, and idle time post-deployment and adjust.

Concept map — tier and compute selection. Follow an edge downward to refine the decision; AHB and reservations apply orthogonally to any vCore SKU.