Azure SQL Database vCore Model Deep Dive: Compute Tier, Service Tier, Read Scale-out, and Reserved Capacity

vCore configuration is decided along 4 axes: Compute Tier, Hardware Generation, Service Tier, and vCore count. Compute Tier: Provisioned (fixed vCores, always-on, production-oriented) vs Serverless (Auto-pause / Auto-resume, dev or low-frequency workloads). Hardware Generation: Standard-series (Gen5, latest general-purpose), Premium-series (fast memory, low latency), and Memory-optimized (3x memory). Service Tier: General Purpose (GP, general-purpose, cheapest), Business Critical (BC, low latency with local SSD), and Hyperscale (HS, ultra-large 100 TB+). vCore count: scale from 2 to several dozen vCores. Standard patterns: general web apps start with GP Standard 4 vCore Provisioned, production mission-critical DBs start with BC Premium 8 vCore, and large DWs start on Hyperscale.

General Purpose (GP): general-purpose tier with Premium SSD remote storage, separate compute and storage, 99.99% SLA, lowest cost. Ideal for general web apps and staging DBs. Business Critical (BC): high-performance tier built on local SSD + Always On AG with 3 replicas for HA, 99.995% SLA, low latency and highest IOPS. Read scale-out is available via read replicas. Aimed at production mission-critical DBs, roughly 2x the cost of GP. Hyperscale (HS): ultra-large tier with a different architecture (Log Service + Compute + Page Server), supports DBs up to 100 TB+, up to 4 read replicas, 99.99% SLA, near-instant snapshot backups, and many Hyperscale-only features. Targeted at 100 TB+ DWs and large SaaS DBs.

The Serverless compute tier is a pay-only-when-used compute mode with automatic pause and resume, available only for SQL Database (Single Database) — not for Managed Instance or Hyperscale. How it works: you set a vCore range (e.g., 0.5-2 vCores), it autoscales with usage, and after an idle period exceeding the Auto-pause Delay (1 hour to 7 days) it stops automatically (compute charges drop to zero, only storage is billed). A new connection triggers an auto-resume (cold start takes about a minute). Typical use cases: (1) dev/test environments, (2) reporting DBs used only a few times a month, (3) variable workloads with unpredictable demand, and (4) startups prioritizing cost minimization. For production mission-critical workloads, cold-start and auto-pause behavior is unsuitable — choose Provisioned instead.

Read Scale-out distributes read workloads across read-only secondary replicas. BC tier: ships with 3 replicas, and you can use one as a Read Scale-out replica at no extra cost by setting ApplicationIntent=ReadOnly on the connection string. HS tier: you can add up to 4 dedicated Read Scale-out replicas (Named Replicas, GA in 2022) and segregate them by use case (BI, reporting, analytics). For read-heavy workloads (80%+ reads), separating the write primary from read replicas significantly reduces load on the primary and boosts overall throughput. The app side needs to add ApplicationIntent=ReadOnly to read-path SQL — ORMs like Entity Framework and Hibernate support this.

Under the vCore model, Reserved Capacity (1-3 year commitment) gives up to 55% off, Hybrid Benefit (bring-your-own SQL Server licenses) gives up to 55% off, and stacking both can deliver up to 80% off. Reserved Capacity applies only to the Compute (vCore) portion; storage, backup, and Long-term Retention remain pay-as-you-go. Hybrid Benefit lets you bring existing SQL Server Standard / Enterprise vCore licenses (with Software Assurance) into Azure and waive the license cost for Azure SQL DB, MI, and SQL on VM. SQL Server Standard 4 vCore converts 1:1 to Azure SQL DB Standard 4 vCore or Azure SQL MI General Purpose 4 vCore. Enterprise converts 1:4 (1 vCore -> 4 Azure vCores) for dramatic savings. Stacking both is the standard play in production.

Auto-failover Group: cross-region HA/DR with bulk failover for multiple DBs, transparent connectivity via Read-Write and Read-Only Listeners, supports Auto-failover (automatic on failure) or Manual-failover (for DR drills), RPO 5s / RTO 1h, and lets you read from the secondary with ApplicationIntent=ReadOnly. Active Geo-replication: DB-level asynchronous replication, up to 4 read secondaries, Manual-failover only, more flexible but without a Listener (the app must switch endpoints). It is also used internally as a building block of Auto-failover Groups. In production, Auto-failover Groups are the default choice (Listeners drastically reduce operational burden); use Active Geo-replication only when you need a one-off read replica or multiple secondaries. Both can be combined with Zone Redundancy on the BC tier.

Azure SQL DB backups are fully automatic and free for short-term PITR. Short-term PITR (Point-in-time Restore): 1-35 days (default 7), auto-captured with geo-redundant storage. Long-term Retention (LTR): retains up to 10 years with Weekly / Monthly / Yearly retention policies on geo-redundant storage. Restore: both PITR and LTR can target the same logical server, a different server, or even a different region. Typical configurations: (1) PITR 7 days (default) + LTR Weekly 4 weeks + Monthly 12 months + Yearly 7 years (for tax-record requirements), or (2) PITR 35 days (for regulated industries) + LTR 10 years. Backup storage lives on Geo-redundant Backup Storage, with LRS / GRS / GZRS options (default RA-GRS). In production, LTR retention design is critical and starts with a compliance-requirements analysis.

DP-300 (Database Administrator Associate) is the headline certification for this area, with deep coverage of vCore models, service tiers, and HADR. AZ-204 (Developer Associate) covers Azure SQL DB SDK operations from a developer angle, AZ-305 (Solutions Architect Expert) covers database selection from an architect angle, DP-700 (Fabric Data Engineer) covers data-integration use cases, SC-300 (Identity Admin) covers Entra ID auth integration, and SC-100 (Cybersecurity Architect Expert) covers data-protection architecture. Azure SQL DB vCore design is at the core of enterprise database operations.