Azure SQL Pricing Tier - Azure Lessons

A software company I worked with moved its customer portal to Azure SQL Database and picked the biggest, safest-sounding option for every environment. Dev, test, and production all ran on Business Critical. Three months later the finance team asked why a database serving 40 internal testers cost nearly as much as production. Nobody had matched the tier to the workload.

Choosing the wrong Azure SQL pricing tier is one of the easiest ways to overspend, and one of the easiest to fix. Azure SQL Database lets you change tiers online, so you can start small, measure, and adjust. But you need to know what each tier pays for first.

This guide compares the DTU and vCore models, explains General Purpose, Business Critical, Hyperscale, and serverless, and shows you how to deploy and resize a database with the CLI and Bicep. You will also learn how to secure it, monitor spend, and troubleshoot the surprises that raise the bill.

Azure SQL Pricing Tier Options Explained

Azure SQL Database has two purchasing models, which are the ways Azure measures and bills your database resources.

The DTU model bundles compute, memory, and I/O into one unit called a database transaction unit (DTU). You pick a service tier (Basic, Standard, or Premium) and a performance level. It is simple, and storage is bundled in. The trade-off is that you cannot scale CPU and storage separately.

The vCore model lets you choose virtual cores (vCores), memory, and storage independently. A vCore is a logical CPU. Microsoft recommends this model for new work, and it unlocks the most features.

Feature	DTU model	vCore model
Resource control	Bundled	Compute and storage chosen separately
Service tiers	Basic, Standard, Premium	General Purpose, Business Critical, Hyperscale
Serverless compute	No	Yes (General Purpose and Hyperscale)
Azure Hybrid Benefit	No	Yes (not for new Hyperscale databases)
Reserved capacity	No	Yes (provisioned compute)
Best for	Simple, predictable workloads	Flexibility, control, and discounts

If you are comparing deployment options before picking a tier, read the guide to Azure SQL Database deployment options. For a broader view of the tier families, see the explainer on Azure SQL Database service tiers. For a general pricing overview, check Azure SQL Database pricing.

I am not quoting dollar amounts in this article. Prices change by region, hardware, and offer type. Always price your exact configuration in the Azure pricing calculator before you commit.

Pro Tip: In my experience, new projects should start in the vCore model, even small ones. The DTU model is fine for simple apps, but it removes your best discount options later.

Compare the vCore Service Tiers

Within the vCore model, three service tiers determine your storage type, resilience, and price.

Tier	Best for	Storage	Replicas	Size limit
General Purpose	Most business apps, budget-friendly	Remote premium storage	One replica	Up to 4 TB
Business Critical	High-transaction OLTP with low latency	Local SSD	Three replicas, one readable secondary	Up to 4 TB
Hyperscale	Large, fast-growing, or read-heavy databases	Decoupled storage with SSD cache	Configurable, up to 4 HA replicas	Up to 128 TB

Here is how I explain the differences.

General Purpose is the default for most workloads. Compute and storage are separate, and Azure Blob storage protects your files. It suits line-of-business apps, internal portals, and APIs where a few milliseconds of storage latency do not matter.

Business Critical runs on local SSD storage with extra replicas for fast failover. Microsoft states that the additional replicas make it cost roughly 2.7 times as much as General Purpose. Choose it when you need very low I/O latency, fast recovery, or a free readable secondary for reports. Do not choose it just to feel safe.

Hyperscale separates compute and storage so each can scale on its own. You are billed for storage you actually allocate, and you can scale compute quickly. Microsoft calls it the recommended tier for many new workloads. Migrating a large database into it takes time because the move depends on data size. You can reverse-migrate to General Purpose only within 45 days, so test before you commit.

Provisioned vs. Serverless Compute

Inside the vCore model, you also choose how compute is billed.

Provisioned compute reserves a fixed number of vCores and bills at an hourly rate whether or not anyone uses the database.
Serverless compute scales within a vCore range you set and bills per second for what it uses. In General Purpose, it can also auto-pause when idle, so you pay only for storage during that time.

Serverless fits dev and test databases, internal tools, and new apps with unknown traffic. It does not fit steady production traffic, because the per-vCore rate is higher than provisioned and a paused database needs time to resume. A resume usually takes about a minute, and the first connection may fail with error 40613, so your app needs retry logic. Auto-pause for Hyperscale serverless is still in preview, so avoid it for production. Also remember that Azure Hybrid Benefit and reservations do not apply to serverless.

For a deeper walkthrough, read the Azure SQL Database serverless guide.

Elastic Pools and the Free Offer

An elastic pool shares one pool of resources across many databases. It works well for SaaS apps with one database per customer, where peaks happen at different times. You pay for the pool, not each database.

There is also a free offer for new databases. At the time of writing, each free database gets 100,000 vCore seconds of serverless compute plus 32 GB of data storage and 32 GB of backup storage per month, with up to 10 free databases per subscription. Microsoft says it has no service level agreement, so use it for learning and proof-of-concept work, not production. Connected tools like SSMS can keep the database awake and burn your free seconds, so disconnect when you are done.

Pro Tip: I keep a simple rule for tier approvals: General Purpose first, Business Critical only with a written latency or failover requirement, and Hyperscale only when size or read scale is the real bottleneck.

How to Choose the Right Azure SQL Pricing Tier

Follow these steps to match a tier to a real workload.

Define the requirement. Write down database size, expected growth, peak hours, latency needs, and recovery goals. A 50 GB internal app and a 5 TB reporting platform need different tiers.
Measure existing usage. If you are migrating, capture CPU, memory, and I/O from the source server for at least a full business cycle. Use Azure’s migration and sizing tools instead of guessing. A common mistake is mapping one on-premises core to one vCore. Azure vCores are logical threads, so under-sizing is likely.
Pick the purchasing model. Use vCore unless you want bundled simplicity and have no license or reservation plans.
Pick the service tier. Start with General Purpose. Move up only when metrics show a real limit.
Pick provisioned or serverless. Choose serverless if the database sits idle for hours. Choose provisioned for steady traffic.
Right-size and review. Start small, watch metrics for two to four weeks, and adjust.

Here are examples of how this plays out in real projects:

Internal HR portal, 200 GB, business-hours traffic: General Purpose provisioned, small vCore count, with a reservation after usage stabilizes.
Developer sandbox, used a few hours a day: General Purpose serverless with auto-pause. Dev and test environments should almost never match production size.
Order processing system with strict latency needs: Business Critical, with zone redundancy where available.
Analytics-heavy platform growing past 4 TB: Hyperscale, with named replicas for reporting.
SaaS app with 300 small tenant databases: An elastic pool sized to combined peaks.

Remember that storage billing differs by tier. In General Purpose and Business Critical, you pay for the maximum data size you configure, and extra space for the log file is added automatically.

In Hyperscale, you pay for allocated storage, and you do not pay for log storage. Backup storage is billed on top, and by default you get backup storage equal to your maximum data size at no extra charge.

Pro Tip: I set the maximum database size close to real need plus growth headroom. Setting a 1 TB maximum “just in case” on a General Purpose database means paying for 1 TB every month.

Deploy and Resize an Azure SQL Database

Let’s build a cost-aware database. The scenario is a customer portal with a dev database that sits idle at night.

Create a resource group first. It is a logical container that holds related Azure resources. See how to create a resource group in Azure if you prefer the portal.

az group create \
  --name rg-portal-dev \
  --location eastus \
  --tags owner=app-team costcenter=engineering environment=dev

This creates rg-portal-dev in East US. The tags assign an owner and cost center, so you can trace spend later. Learn more about Azure tags.

Now create the logical server. It uses Microsoft Entra-only authentication, which means no SQL password exists to leak:

az sql server create \
  --name <sql-server-name> \
  --resource-group rg-portal-dev \
  --location eastus \
  --enable-ad-only-auth \
  --external-admin-principal-type Group \
  --external-admin-name <entra-admin-group-name> \
  --external-admin-sid <entra-admin-group-object-id>

Here is what the parameters do:

--enable-ad-only-auth turns off SQL logins, so everyone signs in through Microsoft Entra ID.
--external-admin-principal-type Group makes the administrator an Entra group instead of one person. When someone leaves, you remove them from the group.
--external-admin-sid is the group’s object ID.

If Entra ID is new to you, start with the Microsoft Entra ID tutorial for beginners. For general creation steps, follow how to create an Azure SQL database.

Create a serverless dev database:

az sql db create \
  --resource-group rg-portal-dev \
  --server <sql-server-name> \
  --name sqldb-portal-dev \
  --edition GeneralPurpose \
  --family Gen5 \
  --compute-model Serverless \
  --capacity 2 \
  --min-capacity 0.5 \
  --auto-pause-delay 60 \
  --max-size 32GB \
  --backup-storage-redundancy Local

Here is why each choice matters:

--edition GeneralPurpose and --family Gen5 select the budget-friendly tier on standard-series hardware, which serverless requires.
--compute-model Serverless bills per second for compute used.
--capacity 2 is the maximum vCores, and --min-capacity 0.5 is the minimum. The range controls both performance and the cost floor.
--auto-pause-delay 60 pauses the database after 60 idle minutes.
--max-size 32GB keeps storage billing small.
--backup-storage-redundancy Local is cheaper but weaker. Use it for dev only. Production data should use zone or geo redundancy.

Change the Tier Later

When production is ready, change the same database to provisioned compute with more vCores:

az sql db update \
  --resource-group rg-portal-dev \
  --server <sql-server-name> \
  --name sqldb-portal-dev \
  --edition GeneralPurpose \
  --family Gen5 \
  --capacity 4 \
  --compute-model Provisioned

This scales the database to four provisioned vCores. The change happens online, but connections are dropped briefly when the switch completes, so your app must retry. Warning: scaling up increases your bill immediately, and larger sizes bill by the hour. Do it in a planned window and confirm the new size. For more resizing options, see how to scale up an Azure SQL database.

Secure the Database Without Raising Costs

Security settings and cost settings often overlap, so decide both together.

Use identity, not passwords. Entra ID sign-in supports multifactor authentication. Apps should use a managed identity, which lets an Azure service authenticate without a stored secret. Read what a managed identity in Azure is. Grant access through Azure RBAC and database roles using the least privilege that works. Learn the basics in what Azure RBAC is.

Protect secrets. If a legacy app needs a password, keep it in Azure Key Vault instead of code, spreadsheets, or shared files. See how Azure Key Vault works. When you must connect with a string, review a safe Azure SQL Database connection string example.

Limit network exposure. Prefer a private endpoint, which gives the database a private IP address in your virtual network. Follow how to create a private endpoint in Azure. If you must use firewall rules, allow only specific IP ranges and never a wide-open range. If clients cannot connect, check the Azure SQL Database IP address guidance and the cannot open server error.

Turn on auditing. Auditing records who did what and helps alert on sensitive actions. Read how to configure Azure SQL Database auditing. Remember that auditing, threat detection, and long-term backup retention can add cost or prevent serverless auto-pause, so enable them where the risk justifies it.

Test with a non-administrator account. Sign in as a user with read-only database rights and confirm that updates and schema changes fail.

Pro Tip: I once saw a serverless dev database that never paused because a monitoring tool polled it every few minutes. Always check what is touching a database before you blame the tier.

Monitor Usage and Control Spend

You cannot right-size a tier without data. Use Azure Monitor, which collects metrics and triggers alerts. Learn what Azure Monitor does. Watch these metrics on each database:

CPU percentage, and DTU percentage if you use the DTU model
Data I/O and log I/O percentage
Storage used versus maximum size
Connection failures and deadlocks
“Free amount remaining,” if you use the free offer

Inside the database, you can check recent resource use with T-SQL:

SELECT TOP (20)
    end_time,
    avg_cpu_percent,
    avg_data_io_percent,
    avg_log_write_percent,
    avg_memory_usage_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;

This view shows recent usage in short intervals. If CPU and I/O stay under about 30 percent for weeks, you are probably over-provisioned. If CPU sits above 80 percent most of the day, you are probably under-provisioned. Also look at Query Store for the heaviest queries, because one missing index can look like a tier problem.

You can list your databases and their SKUs from PowerShell:

$ResourceGroupName = "rg-portal-dev"
$ServerName = "<sql-server-name>"

Get-AzSqlDatabase -ResourceGroupName $ResourceGroupName -ServerName $ServerName |
  Select-Object DatabaseName, Edition, CurrentServiceObjectiveName, Status

This returns each database with its edition and current service objective, which is the quickest way to find a database sitting on a bigger tier than you intended. See the Get-AzSqlDatabase guide for more fields.

Cost Controls That Work

Budgets and alerts: Set alerts at 50, 80, and 100 percent of a monthly budget. See Azure budget alerts.
Azure Advisor: Review right-sizing recommendations monthly. Learn what Azure Advisor is.
Reservations: For steady, provisioned vCore compute, a one- or three-year commitment lowers the compute rate. Compare options in Savings Plan vs. Reserved Instances. Reservations do not cover DTU databases or serverless compute, so buy them only after usage is stable.
Azure Hybrid Benefit: If you own SQL Server licenses with Software Assurance, you may reduce vCore compute costs. Read about the Azure Hybrid Benefit. It is not available for new Hyperscale databases.
Backups and retention: Backup storage beyond the free allowance is billed. Keep retention to what policy requires. Point-in-time restore defaults to seven days and can reach 35 days, and long-term retention can run up to ten years. Learn how to back up an Azure SQL database.
General review: Use these Azure cost optimization best practices as a monthly checklist.

Use different settings per environment. Dev and test should use serverless, local backup redundancy, and short retention. Production should use zone redundancy where supported, the retention your business needs, and a tested restore process.

Pro Tip: In my experience, the cheapest savings come from fixing the dev and test estates first. Moving ten idle databases to serverless usually saves more than negotiating a discount on one production database.

Test and Troubleshoot Tier Changes

Before you call a tier decision final, run these tests:

Normal load: Run a typical business day against the database and confirm CPU, I/O, and response times stay within your targets.
Peak load: Replay a month-end report or batch job. Confirm the tier handles it without timeouts.
Failure and recovery: Restore a copy from point-in-time backup into a test database and time it. Test a failover if you use zone redundancy or geo-replication.
Unauthorized access: Sign in as a user without database rights and confirm access is denied.

These are the problems I see most often:

Error 40613 after idle time: A serverless database was paused. Retry the connection and add retry logic to the app.
Serverless database never pauses: Open sessions, geo-replication, long-term retention, or a DNS alias prevent auto-pause. Find and disconnect idle sessions, or switch to provisioned.
Costs jumped after scaling: A larger SKU bills hourly. Check the current service objective and scale back if the peak has passed.
Cannot reach the maximum size you want: Each tier and vCore size has a storage limit. Review the Azure SQL Database limitations before you plan.
Cannot choose the tier you want: The region, offer type, or quota may block it. Request a quota increase or try another supported region.
Free database became inaccessible: The free monthly allowance ran out, and the database was set to auto-pause until next month. Switch to the paid option if you need continuous use.Pro Tip: Whenever I change a tier, I note the date, old size, new size, and reason in the project wiki. Six months later, that history answers most cost questions in minutes.

Azure Cost and Scaling Considerations

Start with General Purpose: Move to Business Critical or Hyperscale only when latency, failover, size, or read scale is a documented requirement.
Match compute to usage: Use serverless for idle-heavy workloads and provisioned compute for steady traffic. Remember serverless trades a higher active rate for lower idle cost.
Set realistic maximum sizes: General Purpose and Business Critical bill for configured maximum data size, so avoid oversized limits.
Commit only after stability: Reservations and Azure Hybrid Benefit help most when usage is predictable, so measure for several weeks first.
Secure by default: Use Entra-only authentication, managed identities, private endpoints, and auditing, and test with a least-privilege account.
Separate environments: Give dev, test, and production different tiers, redundancy, retention, budgets, and tags.

Frequently Asked Questions

What are the Azure SQL Database pricing tiers?

The vCore model has General Purpose, Business Critical, and Hyperscale. The DTU model has Basic, Standard, and Premium. You also choose provisioned or serverless compute in the vCore model.

Is DTU or vCore better for Azure SQL?

vCore is the better default for most new databases because it separates compute and storage and supports reservations, Hybrid Benefit, serverless, and Hyperscale. DTU is simpler for small, predictable workloads. You can convert between models online.

Can I change the Azure SQL pricing tier later?

Yes. You can change tiers and sizes with the portal, CLI, PowerShell, T-SQL, or REST. Connections drop briefly when the change completes, so use retry logic. Moving into Hyperscale takes longer for large databases, and reverse migration has a time limit.

Is Azure SQL serverless cheaper?

It is cheaper for databases that are idle for long stretches because paused databases bill only for storage. For busy databases, provisioned compute usually costs less per vCore. Serverless is also not eligible for reservations or Azure Hybrid Benefit.

Is there a free Azure SQL Database?

Yes. The free offer gives each database a monthly allowance of serverless compute and storage, with a limit of ten free databases per subscription. It has no SLA, so use it for learning and proofs of concept.

You learned how DTU, vCore, serverless, and Hyperscale options work, and how to deploy and resize an Azure SQL database safely. The key principle is to start small, measure real usage, and tag and budget every environment so tier decisions follow data and not guesses. I hope you found this article helpful.