If there’s one decision that trips up almost everyone new to Azure SQL and quietly costs experienced teams real money when they get it wrong — it’s picking a service tier. Not because the options are poorly documented, but because Microsoft genuinely gives you four different ways to think about “how much database do I need,” and each one optimizes for a different problem.
This article walks through all four – DTU, vCore, Serverless, and Hyperscale, the way I’d actually explain them to a team making this decision for real, including where each one quietly stops making sense.
DTU vs vCore
Before you can even think about Serverless or Hyperscale, you have to pick a purchasing model. This is the foundational decision everything else sits on top of.
What DTU actually is
DTU (Database Transaction Unit) is a blended measure. Microsoft bundles CPU, memory, and I/O into a single number and sells you tiers of that bundle: Basic, Standard, Premium. You don’t choose CPU cores separately from memory; you choose a tier, and the ratio of resources is fixed by Microsoft.
Think of it like buying a pre-built combo meal instead of ordering items individually. It’s simple, it’s fast to reason about, and for a genuinely small, simple workload, it’s honestly fine.
The catch: you can’t scale one dimension independently. If your workload is CPU-hungry but doesn’t need much I/O, you’re still paying for I/O capacity bundled into the tier you picked. You have no visibility into which specific resource is actually constraining you without digging into the DTU percentage metric and inferring.
What vCore actually is
vCore lets you choose CPU cores and memory independently, giving you a much more transparent, granular way to size a database. It also unlocks:
- Azure Hybrid Benefit — reusing existing on-prem SQL Server licenses to cut compute cost, often by a meaningful margin
- Independent choice of hardware generation
- Access to every other tier discussed in this article — Serverless and Hyperscale are both vCore-only. There’s no DTU version of either.
DTU vs vCore – the direct comparison
| Aspect | DTU Model | vCore Model |
|---|---|---|
| Resource control | Bundled (CPU+memory+I/O fixed together) | Independent (choose CPU and memory separately) |
| Transparency | Low — one blended number | High — you know exactly what you’re paying for |
| License reuse (Hybrid Benefit) | Not available | Available |
| Access to Serverless | No | Yes |
| Access to Hyperscale | No | Yes |
| Access to Business Critical HA architecture | Only via Premium tier (limited) | Yes, full Business Critical tier |
| Best for | Simple, well-understood, small workloads | Everything else |
When to use DTU: a genuinely small, simple database — a dev/test environment, a small internal tool, a proof of concept — where you want the fewest decisions to make and you’re not going to outgrow Standard or Premium tier anytime soon.
When not to use DTU: basically any production workload with real growth expectations, anything where you already own SQL Server licenses you’d want to reuse, or anything where you’ll eventually want Serverless or Hyperscale — because migrating from DTU to vCore later is an extra step you could just skip by starting on vCore.
Honestly, for new projects in 2026, I default to vCore almost every time unless someone gives me a specific reason not to. DTU still exists mostly for legacy continuity and genuine simplicity at small scale.
Inside vCore: General Purpose vs Business Critical
Once you’re on vCore, you’re choosing a service tier within it. The two “always-on, provisioned” tiers are General Purpose and Business Critical (Serverless and Hyperscale are their own separate tracks, covered below).
- General Purpose — compute and storage are separated; storage lives on remote, redundant Azure Premium storage. If the compute node fails, a new one spins up and reattaches to that same durable storage. Cheaper, and the default sensible choice for most workloads.
- Business Critical — runs four replicas (one primary, three synchronized secondaries) with local, directly-attached storage, similar in spirit to SQL Server Always On Availability Groups. Failover is much faster (often under 30 seconds) since there’s no storage reattachment involved, and one of those secondaries can serve read-only traffic (read scale-out) at no extra cost.
When to use Business Critical: you have a genuine, specific requirement for sub-30-second failover, or you want to offload reporting queries to a free read-only replica.
When not to: if General Purpose’s failover time (generally still measured in seconds to low minutes) already satisfies your actual documented RTO requirement, Business Critical’s extra cost isn’t buying you anything the business is actually asking for. This is one of the most common over-provisioning mistakes I see — teams pick Business Critical because it “sounds more critical,” without ever checking what RTO the business genuinely needs.
Serverless: for workloads that don’t run all the time
Serverless is a compute tier, not a separate purchasing model — it’s vCore, just billed differently.
What it does: it auto-scales compute up and down based on actual load within a min/max vCore range you configure, and it can auto-pause during genuine inactivity, billing per-second for compute rather than a flat reserved rate. During a pause, you’re only paying for storage.
When to use it:
- Dev/test databases that sit idle most of the day and night
- A new application with genuinely unpredictable, spiky, or low-volume traffic where you don’t yet know what “normal” load looks like
- Intermittent-use internal tools — a monthly reporting database, a seasonal application
When not to use it:
- A steady, always-on production workload with consistent traffic. Serverless’s per-second billing for genuinely continuous usage often works out more expensive than a reserved provisioned tier — its cost advantage comes specifically from variability and idle time, and a workload without much of either doesn’t benefit.
- Anything sensitive to cold-start latency. When a paused database resumes, there’s a real delay (often single-digit seconds, sometimes more) before it’s ready to serve the first connection — unacceptable for a customer-facing app where every millisecond of latency is scrutinized.
- A workload where you already know it needs sustained, predictable compute — in that case, just do the math against a provisioned tier or reserved capacity, since Serverless is solving a problem you don’t have.
A genuinely common mistake: people put Serverless on a production database because it “sounds cost-efficient,” without ever comparing the actual math against provisioned pricing for their specific, steady usage pattern.
Hyperscale: when database size itself is the problem
Hyperscale addresses a completely different constraint than the others: very large databases where backup and restore time scale badly with data size on General Purpose or Business Critical.
What makes it different: Hyperscale uses a distributed, log-structured storage architecture with page servers, each independently responsible for a portion of the data. Because of this, backups are essentially fast metadata operations rather than physically copying the whole data file — meaning backup and restore time stay near-constant regardless of database size, whether you’re at 500GB or 50TB.
It also decouples storage scaling from compute — storage can grow up to 100TB, largely independent of the compute tier you’ve chosen, and supports both HA replicas and separate, workload-isolated read-only “named replicas.”
When to use Hyperscale:
- A database that’s genuinely large today (multi-terabyte) or on a clear growth trajectory toward that scale
- Any scenario where General Purpose or Business Critical’s backup/restore time has become a real operational or RTO risk, not just a theoretical concern
- You need fast, cheap database copies for dev/test refreshes from a large production database
When not to use Hyperscale:
- A small, simple database with no realistic path to large scale. You’re not getting proportional value from Hyperscale’s architecture if the problem it solves (backup/restore time at large scale) was never actually your problem.
- If your team’s primary concern is raw query performance tuning rather than size — Hyperscale isn’t inherently “faster” for a typical OLTP query than Business Critical; its advantage is specifically about scale and backup/restore behavior, not general throughput.
Putting it all together
Here’s the decision flow I actually walk teams through, matching the diagram above:
- Do you need license reuse, Serverless, Hyperscale, or Business Critical’s fast failover? If no, and the workload is genuinely small and simple → DTU is fine.
- Otherwise, you’re on vCore. Now the real question is workload shape:
- Intermittent, spiky, or genuinely idle much of the time → Serverless
- Steady, predictable, always-on → Provisioned (General Purpose by default, Business Critical only if you have a documented sub-30-second RTO or read-scale-out need)
- Very large or fast-growing data volume, where backup/restore time is a genuine concern → Hyperscale
One thing worth being honest about: these aren’t always mutually exclusive in the way a simple flowchart implies. A very large database can also have intermittent usage patterns (though Hyperscale and Serverless compatibility has specific version and configuration considerations worth checking against current Microsoft documentation before assuming they combine freely). The flowchart is a starting point for reasoning, not a rule that removes judgment.
Quick reference table
| Tier | Best for | Avoid when |
|---|---|---|
| DTU | Small, simple, well-understood workloads; dev/test | Any workload with real growth, license reuse needs, or a future need for Serverless/Hyperscale |
| vCore – General Purpose | Most production workloads | You have a documented sub-30-second RTO requirement |
| vCore – Business Critical | Fast failover, free read-scale-out replica | General Purpose already meets your actual RTO; cost isn’t justified by a real requirement |
| Serverless | Intermittent, spiky, or idle-heavy workloads | Steady, always-on production traffic; latency-sensitive apps that can’t tolerate cold start |
| Hyperscale | Very large or fast-growing databases; fast backup/restore at scale | Small databases with no real growth trajectory |
A closing thought
The pattern worth remembering across all four tiers: each one is solving a specific problem – cost simplicity, license reuse, workload variability, or database size — not a general “better performance” upgrade. The teams that get this decision wrong are almost always the ones who picked a tier because it sounded more capable or more premium, rather than because they’d actually matched it against their workload’s real shape. Start from your actual RTO requirement, your actual usage pattern, and your actual data volume trajectory , the right tier falls out of those answers far more reliably than intuition does.
Discover more from Technology with Vivek Johari
Subscribe to get the latest posts sent to your email.
