The vCore model is a way to buy and size Azure SQL capacity using familiar building blocks: cores, memory expectations, storage, and service tier. It is more transparent than the older DTU bundle because architects can reason about compute and storage separately. You still need to choose a tier such as General Purpose, Business Critical, or Hyperscale, but the conversation becomes clearer: how many cores, which compute model, what storage, what availability, and what cost commitment fit the workload?
The vCore purchasing model for Azure SQL lets teams choose compute, service tier, hardware configuration, and storage more transparently than the DTU model. It supports provisioned and serverless compute choices, clearer resource limits, Azure Hybrid Benefit, and reserved capacity options for predictable database workloads.
In Azure SQL Database, the vCore model sits in the control-plane SKU and purchasing layer. It combines service tier, compute tier, hardware family, vCore count, storage size, backup storage, and redundancy into a deployable database configuration. The model supports provisioned compute for steady workloads and serverless options for intermittent use. It also influences resource limits, failover design, migration planning, and reservation strategy. Operators see it in `az sql db` output, ARM or Bicep properties, pricing calculators, and Compute + storage settings.
Why it matters
The vCore model matters because it changes database planning from a single bundled number into explicit architecture decisions. With DTUs, teams often argued about whether CPU, memory, or I/O was hidden inside the unit. With vCore-based choices, engineers can align capacity with workload behavior, compare tiers, estimate migration headroom, and explain cost to finance more clearly. It also unlocks purchasing choices such as reserved capacity and Azure Hybrid Benefit for eligible workloads. The tradeoff is responsibility: teams must understand service tiers, serverless limits, storage, availability, and monitoring instead of assuming the model will automatically choose the right balance. before live traffic depends on it.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
The Azure SQL Compute + storage blade shows the selected vCore model choices, including service tier, compute tier, hardware configuration, and capacity during production sizing reviews.
Signal 02
Bicep, ARM, and Terraform definitions expose vCore-model decisions through SKU, family, capacity, edition, compute model, storage, and redundancy properties in repeatable deployment reviews and pull requests.
Signal 03
Migration assessments, pricing estimates, and FinOps reports compare DTU and vCore model options when teams justify database sizing and licensing decisions for production and non-production databases.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Migrate an Azure SQL workload from DTU to vCore so compute, storage, and cost tradeoffs are easier to explain.
Choose serverless for an intermittent application while setting min and max vCores to control resume behavior and spend.
Separate storage growth from compute scaling when a database stores more history but does not need more CPU.
Apply reserved capacity or Azure Hybrid Benefit to a stable production estate with predictable database compute demand.
Compare General Purpose, Business Critical, and Hyperscale when latency, availability, and storage growth requirements diverge.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Insurance claims system moves beyond DTU guesswork
Insurance claims system moves beyond DTU guesswork: The vCore model is valuable when teams need to replace bundled capacity guesses with explicit compute, storage, licensing, and performance decisions.
📌Scenario
An insurance carrier ran a claims portal on an Azure SQL Database sized with DTUs years earlier. During storm season, nobody could explain whether the bottleneck was CPU, storage, or the pricing model itself.
🎯Business/Technical Objectives
Migrate from DTU to a vCore model with documented performance and cost assumptions.
Keep adjuster claim searches under one second during catastrophe response days.
Use licensing benefits where eligible without changing application code.
Create a repeatable sizing method for future regional claim systems.
✅Solution Using vCore model
Database engineers captured DTU-era metrics, Query Store data, and storm-season transaction samples, then tested General Purpose and Business Critical vCore configurations. The selected vCore model separated compute, storage, and licensing decisions so finance could review Azure Hybrid Benefit assumptions. Azure CLI scripts created test databases with identical capacity and exported SKU, family, and storage settings after each load test. The migration runbook included rollback to the prior service objective and post-change checks for CPU, log rate, and search latency.
📈Results & Business Impact
Claim search p95 latency improved from 1.8 seconds to 740 milliseconds during simulated storm load.
The final vCore model was 22 percent cheaper than the first overprovisioned candidate.
Sizing evidence reduced architecture approval from four review cycles to one.
No user-facing outage occurred during the purchasing-model migration window.
💡Key Takeaway for Glossary Readers
The vCore model is valuable when teams need to replace bundled capacity guesses with explicit compute, storage, licensing, and performance decisions.
Case study 02
Education app uses serverless capacity for uneven demand
Education app uses serverless capacity for uneven demand: The vCore model gives architects room to choose serverless for uneven workloads while keeping critical databases on steadier provisioned capacity.
📌Scenario
An education technology provider hosted practice-test databases that were busy after school and nearly idle overnight. Provisioned capacity made quiet hours more expensive than the traffic justified.
🎯Business/Technical Objectives
Cut compute spend for intermittent test-prep workloads by at least 35 percent.
Keep first-query resume delay acceptable for student practice sessions.
Document min and max capacity so support teams understood scaling behavior.
Avoid changing the application connection model during the cost optimization project.
✅Solution Using vCore model
The data platform team evaluated the vCore model with serverless compute for noncritical practice databases. They set minimum and maximum vCores based on load tests, disabled auto-pause for exam weeks, and kept production teacher-reporting databases on provisioned compute. Azure CLI captured compute model, capacity limits, and auto-pause settings for each database. Support runbooks explained resume behavior and included dashboard links for CPU, app errors, and connection retries so help desk staff would not misdiagnose serverless warm-up as an outage.
📈Results & Business Impact
Compute charges for practice databases fell 41 percent in the first billing cycle.
Median first-query resume delay stayed under 18 seconds, within the support objective.
Exam-week incidents did not increase after auto-pause was disabled for scheduled peaks.
Support tickets about slow first access dropped 30 percent after runbook updates clarified behavior.
💡Key Takeaway for Glossary Readers
The vCore model gives architects room to choose serverless for uneven workloads while keeping critical databases on steadier provisioned capacity.
Case study 03
Media catalog chooses tier before adding cores
Media catalog chooses tier before adding cores: A vCore-model decision should compare tiers and workload behavior, not blindly add cores whenever latency rises.
📌Scenario
A streaming-media catalog stored metadata for millions of assets. The team first planned to double vCores, but latency tests showed storage and read patterns mattered more than CPU alone.
🎯Business/Technical Objectives
Reduce catalog API p95 latency below 300 milliseconds during evening browse peaks.
Avoid paying for extra cores if service tier architecture was the real constraint.
Document when Business Critical was justified over General Purpose.
Keep rollback simple if the new tier changed maintenance or failover expectations.
✅Solution Using vCore model
Architects used the vCore model to test service tiers, not just capacity. They compared General Purpose at higher vCore counts with Business Critical at a smaller vCore count, using the same read-heavy workload and Query Store baselines. Azure CLI exported SKU, family, capacity, and max size after each run, while application tests measured cache misses, storage waits, and API latency. The final design changed tier and capacity together, with a one-step rollback script and a cost review showing why the tier shift was worth more than adding cores alone.
📈Results & Business Impact
Catalog API p95 latency dropped from 620 milliseconds to 255 milliseconds at peak.
The chosen tier used fewer vCores than the original scale-up proposal.
Monthly database cost rose 12 percent, but abandoned browse sessions fell 19 percent.
Rollback testing completed in 14 minutes, meeting the operations safety target.
💡Key Takeaway for Glossary Readers
A vCore-model decision should compare tiers and workload behavior, not blindly add cores whenever latency rises.
Why use Azure CLI for this?
Azure CLI is useful for the vCore model because purchasing choices should be visible in repeatable deployment evidence, not buried in portal screenshots. With CLI, I can inspect edition, compute model, family, capacity, storage, and redundancy across many databases, then compare those settings with performance and cost reports. For migrations, CLI output gives architecture boards proof of what was deployed after tests. For operations, scripts can create databases with known vCore-model settings, detect drift, and apply approved scaling changes. That consistency matters when production capacity and monthly spend are both on the line. It also prevents accidental portal-only drift. Evidence should survive handoffs.
CLI use cases
Create a test database with known vCore-model properties so performance tests match the proposed production architecture.
List SKU and compute-model settings across databases to find environments still using the wrong purchasing model.
Update capacity or compute model only after an approved migration or performance test has documented the target state.
Export service tier, capacity, storage, and redundancy fields for architecture review and FinOps evidence.
Before you run CLI
Confirm the subscription, resource group, logical server, database name, region, and Azure SQL service type before changing SKU settings.
Check whether the workload uses DTU, vCore provisioned, serverless, elastic pool, Hyperscale, or managed instance because options differ.
Review cost impact, availability expectations, maintenance window, and rollback plan before applying a service-tier or compute-model change.
Capture current SKU, edition, family, capacity, max size, and redundancy as JSON so the previous model can be restored if needed.
What output tells you
SKU fields show whether the database is using vCore-model capacity and which service tier, family, and capacity are configured.
Compute model fields tell whether the workload is provisioned or serverless, which changes billing behavior and cold-start expectations.
Storage and redundancy fields reveal whether cost or resilience changed alongside compute, not just the vCore count.
Provisioning state and location confirm whether the requested model change completed on the intended database in the intended region.
Mapped Azure CLI commands
Azure SQL vCore model commands
direct
az sql db create --name <database> --server <sql-server> --resource-group <resource-group> --edition GeneralPurpose --family Gen5 --capacity <vcores>
az sql dbprovisionDatabases
az sql db show --name <database> --server <sql-server> --resource-group <resource-group>
az sql dbdiscoverDatabases
az sql db update --name <database> --server <sql-server> --resource-group <resource-group> --edition GeneralPurpose --capacity <vcores>
az sql dbconfigureDatabases
az sql db list-editions --location <region> --edition GeneralPurpose --service-objective <objective>
az sql dbdiscoverDatabases
Architecture context
Architecturally, the vCore model is the decision framework for Azure SQL capacity, not just a SKU label. It asks whether a workload is steady or intermittent, needs local SSD-style performance, benefits from Hyperscale storage architecture, or should live in an elastic pool. It also ties into licensing strategy, reserved capacity, backup storage, geo-replication, and operational monitoring. A strong design documents why the chosen tier, compute model, family, and vCore count meet workload goals. Without that explanation, teams tend to overprovision after incidents or underprovision during migrations because nobody can defend the sizing logic. Review boards should see the tested alternatives, not only the final SKU.
Security
Security impact is indirect but real. The vCore model does not decide who can read data, whether encryption is enabled, or whether a private endpoint exists. It does, however, sit behind permissions that can create, scale, or reconfigure production databases. Those permissions should be restricted because changing the model can affect cost, availability, and incident response. Some model choices also shape where sensitive workloads should run, such as separating regulated production data from cheaper non-production settings. Secure governance means requiring RBAC discipline, policy checks, activity-log review, and approval before service-tier or compute-model changes. Policy can also restrict allowed tiers for regulated environments.
Cost
Cost is one of the main reasons the vCore model exists. It exposes compute, storage, backup storage, tier, and licensing decisions so teams can choose a better fit than a bundled DTU number. Provisioned compute suits steady demand but can waste money when databases sit idle. Serverless can reduce cost for intermittent workloads but may surprise teams if min/max settings or resume behavior are misunderstood. Reserved capacity and Azure Hybrid Benefit can lower predictable spend. Cost control requires reviewing utilization, environment class, reservation coverage, and scale windows instead of treating every database like production. Savings depend on matching the model to actual workload rhythm.
Reliability
Reliability is tied to the vCore model because service tier and compute model influence availability characteristics, maintenance expectations, failover behavior, and performance headroom. A provisioned database may be better for predictable traffic, while serverless can fit intermittent workloads but requires cold-start and auto-pause awareness. Business Critical, General Purpose, and Hyperscale have different architectures and tradeoffs. Reliable designs test failover, backup restore, scale operations, and application retry behavior for the selected model. The danger is assuming all vCore configurations behave alike; they do not, especially under bursty traffic, regional incidents, or storage-heavy workloads. Recovery drills should validate the exact tier rather than a similar one.
Performance
Performance under the vCore model depends on more than the vCore count. Service tier, hardware family, memory, log rate, storage architecture, and workload shape all matter. The model helps because engineers can test those choices more explicitly than with DTUs, but it also demands better analysis. Moving from General Purpose to Business Critical may reduce latency for some workloads, while adding vCores may help CPU-bound queries but not blocking or bad indexing. Operators should use Query Store, wait stats, CPU metrics, and storage signals to decide whether the model choice or the database design needs to change. Test data should include representative concurrency and maintenance periods.
Operations
Operators manage the vCore model by inspecting SKU fields, compute model, service tier, capacity, storage, and backup settings, then matching them against runbooks and monitoring. They use Azure CLI, Bicep, Azure Policy, Query Store, and cost exports to detect drift from approved patterns. Production changes should record the before state, target state, expected cost impact, workload window, and rollback option. During incidents, operators should decide whether scaling compute, changing tier, optimizing queries, or moving to a different model is appropriate. Good operations keep the vCore-model decision tied to measurable service objectives. Architecture decision records should reference the measured workload and approved fallback model.
Common mistakes
Calling the vCore model a simple scale setting and ignoring service tier, storage architecture, hardware family, and licensing choices.
Migrating from DTU to vCore without measuring CPU, I/O, waits, and business workload windows first.
Choosing serverless only for lower cost while forgetting resume latency, minimum capacity, and unpredictable traffic spikes.
Letting every environment inherit production vCore-model settings, which makes dev and test databases unnecessarily expensive.