Purchasing models: DTU, vCore and serverless

The second DBA clinic starts with a spreadsheet. Dana Whitcombe, the chief financial officer, has asked for a cost range for every Skylight database before the 2027 budget is signed, and Walt has to produce the numbers for the Azure SQL part. On premises, the cost of StockLine is hidden inside a server purchase made in 2019 and a SQL Server licence renewal that arrives every three years. In Azure it will appear every month on an invoice, line by line. Before Walt can estimate anything, Elena tells him, he needs to understand the ways Azure SQL is sold, because the purchasing model decides which knobs he can turn and what each turn costs.

Elena is strict about one rule, and this course follows it too: real Azure prices change often and differ by region, so every price in the clinic is an illustrative number, clearly labelled, used only to practise the arithmetic. Walt will use the Azure pricing calculator and the company's own agreement for the real budget.

Two purchasing models

Azure SQL Database offers two purchasing models. The DTU model sells a bundled measure of performance. The vCore model sells compute, memory and storage as separate, visible quantities. Azure SQL Managed Instance offers only the vCore model, and SQL Server on Azure Virtual Machines is priced differently again: you pay for the virtual machine and its disks, plus a SQL Server licence that is either included in the hourly rate or brought from the company's existing agreements.

The DTU model is older and simpler. A database transaction unit blends processor, memory, reads and writes into one number, and you buy a service objective that provides a fixed amount: the Basic tier for small, light databases, the Standard tier with sizes from S0 upward, and the Premium tier for heavier input and output. Each size comes with a fixed maximum database size and a fixed level of performance. The model suits small, predictable workloads and people who would rather not think about hardware, but it gives you little control: you cannot add memory without adding processor, and you cannot use existing SQL Server licences to lower the price.

The vCore model is the one Microsoft recommends for most new work, and it is the model the DP-300 exam spends most time on. A vCore is a virtual processor core. You choose a service tier, a hardware configuration and a number of vCores, and storage is billed separately according to how much you allocate. Because compute and storage are separate, you can size each to its own need. Because the licence is visible, you can apply Azure Hybrid Benefit and pay a lower rate for compute if the company owns SQL Server licences with Software Assurance or a qualifying subscription. And because capacity is described in familiar units, it is easier to compare an Azure database with an on-premises server that has, say, eight cores and 64 GB of memory.

Service tiers in the vCore model

Within the vCore model, three service tiers describe the architecture underneath the database. General Purpose separates compute from storage: the database files sit on remote premium storage, and if the compute node fails, a new node attaches to the same files. It is the budget-friendly default and suits most business applications. Business Critical keeps the data on fast local SSD storage and runs several replicas in an Always On availability group behind the scenes, which gives lower input and output latency, faster failover and a free readable secondary replica for reporting. It costs noticeably more. Hyperscale uses a distributed architecture with separate page servers and a log service, which lets a single database grow to very large sizes and scale compute quickly; lesson 10 is devoted to it.

Managed Instance uses the same names with one addition. Its General Purpose and Business Critical tiers work in the same way as in SQL Database, and the Next-gen General Purpose option, generally available since November 2025, keeps the General Purpose design but lets you raise storage performance and the number of databases per instance more flexibly than the original version. Hyperscale is not a Managed Instance tier.

Hardware configurations sit underneath the tiers. Standard-series hardware, sometimes still called Gen5 in older documents, is the common default. Premium-series and memory-optimized options offer newer processors or more memory per vCore at a higher price. For the exam, the point to remember is that the hardware choice changes the ratio of memory to vCores and the maximum size available, and that serverless runs only on standard-series hardware.

Provisioned and serverless compute

In the vCore model, Azure SQL Database also offers two compute tiers. Provisioned compute is what most people picture: you choose a number of vCores and pay for them every hour, whether the database is busy or idle, until you change the size. Serverless compute is different. You choose a minimum and a maximum number of vCores, and the database scales automatically between them according to demand. Billing is per second, based on the vCores and memory actually used, but never less than the minimum you set while the database is online.

A serverless database in the General Purpose tier can also pause automatically when it has been idle for a chosen period, called the auto-pause delay. While paused, compute costs nothing and only storage is billed. The next connection wakes the database, and that first connection waits while compute is brought back, often for a minute or so, which is why applications that use serverless should retry their first connection. The auto-pause delay can be as short as 15 minutes in General Purpose; Hyperscale serverless supports pausing only as a preview feature, with a longer minimum delay. Auto-pause can also be turned off entirely, which keeps the per-second scaling but removes the wake-up delay.

Serverless is not always cheaper. Because the price per vCore second is higher than the provisioned rate, a database that is busy all day costs more on serverless than on a provisioned size that matches its load. The model shines for intermittent, unpredictable or development workloads: test databases used during office hours, a new application whose demand is still unknown, or a reporting database queried for a few hours each night.

# Compare provisioned and serverless compute cost for one week (illustrative prices).
prov_rate = 0.50          # dollars per hour for 2 provisioned vCores
sl_rate = 0.20            # dollars per vCore hour for serverless
min_vcores = 0.5
week = []                 # (hours, average vCores used, paused?) blocks
for day in range(7):
    if day < 5:           # Monday to Friday
        week.append((10, 1.5, False))   # busy hours
        week.append((1, 0.0, False))    # idle, waiting to pause
        week.append((13, 0.0, True))    # paused overnight
    else:
        week.append((24, 0.0, True))    # paused all weekend
prov = 24 * 7 * prov_rate
sl = 0.0
for hours, used, paused in week:
    if not paused:
        sl += hours * max(used, min_vcores) * sl_rate
print("Provisioned compute:", round(prov, 2), "dollars")
print("Serverless compute: ", round(sl, 2), "dollars")
print("Serverless costs", round(sl / prov, 2), "times as much as provisioned")

Provisioned compute: 84.0 dollars
Serverless compute:  15.5 dollars
Serverless costs 0.18 times as much as provisioned

The same arithmetic shows when serverless loses. If the Finch Rewards production database will be busy from early morning until late at night every day of the week, averaging close to 2 vCores for 18 hours a day, serverless would bill roughly 18 × 7 × 2 × 0.20 = 50.40 dollars of compute a week before counting the quieter hours, and the gap to the provisioned 84.00 dollars closes quickly as usage rises. That is why the team chose provisioned compute for production: steady load is cheaper on a fixed size, and the wake-up delay of a paused database is unacceptable for a customer-facing app.

How serverless counts memory

One detail of serverless billing catches people out. Serverless measures the larger of two things each second: the vCores in use, and the memory in use converted into vCore terms. Memory counts as one vCore for every 3 GB, in the standard-series hardware this course uses. A database that keeps a large cache in memory but uses little processor can therefore be billed for more vCores than its processor use suggests. The engine reclaims cache memory gradually when it is not being used, but a workload that reads a large working set over and over keeps memory high. For estimating, Walt notes simply that the bill follows the busier of processor and memory, and never goes below the minimum vCores configured.

Licences and reservations

Two more levers apply to provisioned vCore compute and to Managed Instance. Azure Hybrid Benefit lets a company that owns SQL Server Enterprise or Standard licences with Software Assurance, or SQL Server subscription licences, pay a reduced compute rate in Azure that excludes the licence cost. On a SQL Server virtual machine the same benefit removes the SQL licence from the hourly rate. Reserved capacity lets a company commit to a quantity of vCores in a region for one or three years in exchange for a lower rate; it suits steady production databases such as StockLine, but not test databases that come and go. Neither lever applies to serverless compute, which is always billed at its own per-second rate.

Licensing also changes the picture for development. The free SQL Server Developer edition can run on a test virtual machine at no licence cost, and Azure SQL Database offers a free monthly allowance for a limited number of small databases, which suits training and experiments. Walt plans to use the free offer for his own DP-300 practice databases, because it lets him repeat the exercises in this course without adding a line to Dana's invoice.

DTU or vCore?

For the exam, recognise the signals. DTU suits a small, simple, predictable database where the team wants a single number to choose and does not have licences to reuse. vCore suits almost everything else: databases that need more memory or storage than processor, any database where Azure Hybrid Benefit or reservations apply, any Managed Instance, and anything that needs serverless, Business Critical features or Hyperscale. Moving from one model to the other is an online scaling operation, so a database that starts on DTU can move to vCore later. A rough guide that Microsoft documents is that about 100 DTUs in the Basic or Standard tiers correspond to about one vCore of General Purpose, and about 125 DTUs in Premium to about one vCore of Business Critical; treat that only as a starting point and confirm with monitoring after the change.