2. Core Concepts

Every noun you will meet in the portal, defined. The pattern on this page is always term → plain-English analogy → precise technical definition, because the fastest way to get lost in Azure SQL is to half-know what a "DTU" or a "logical server" is and keep going.

The resource shape

Two ARM resources matter, and one thing that looks like a resource but isn't:

Term	Analogy	Technical definition
Logical server	A street address with a lock on the gate — no house yet	An ARM resource of type Microsoft.Sql/servers. It owns the globally unique DNS name <name>.database.windows.net, the administrator identity (SQL admin and/or Entra admin), the firewall and virtual network rules, the auditing and threat-protection configuration, and the private endpoint attachment. It has no compute and no cost of its own
Database	The house at that address, with its own meter	An ARM resource of type Microsoft.Sql/servers/databases. It owns its own compute allocation, storage, service tier, collation, backup retention, and geo-replication configuration. This is the unit of billing, scaling, restore, and failover
Elastic pool	A shared meter for a street of houses	Microsoft.Sql/servers/elasticPools. A pool of compute that a set of databases on the same logical server draw from, instead of each holding a private allocation. The pool is billed; the databases in it are not billed for compute
master	The porter's logbook, not a room you can use	A system database on the logical server exposing logins, firewall rules, and sys.databases. You cannot create user objects in it, and you cannot query across databases from it

The resource ID makes the nesting explicit — this is the string every role assignment, policy assignment, and error message is written against:

/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Sql/servers/{server}/databases/{db}

Scoping, subscriptions, and RBAC inheritance are covered once in the scope hierarchy.

[Image Prompt: 2D minimalistic labelled hierarchy diagram showing a resource group containing a logical SQL server, with the server holding firewall rules, an Entra admin, and auditing settings, and containing three databases plus one elastic pool that two of the databases draw compute from, flat design, clean vector art style, white background]

The two purchasing models

This is the first fork in every sizing conversation, and the vocabulary is not intuitive.

Term	Analogy	Technical definition
DTU (Database Transaction Unit)	A single "power" dial that bundles engine, fuel and gearbox	A blended, opaque measure of CPU, memory, reads and writes. You buy a DTU count in the Basic / Standard / Premium tiers. Simple, older, and impossible to reason about component-wise
vCore	Separate dials for engine size and fuel tank	You buy a number of virtual cores on a named hardware generation, plus storage separately. Memory is derived from the vCore count and hardware family. This is the model everything new uses, and the only one that supports Hyperscale, Serverless, and Azure Hybrid Benefit
Azure Hybrid Benefit	Bringing your own licence to the rental	A discount applied to vCore-model databases when you already own SQL Server licences with Software Assurance. Not available in the DTU model — a common reason to migrate models

Which to pick: vCore, essentially always, for anything new. DTU survives because existing databases run on it and because at the very small end (Basic) it is cheap and simple. The migration between models is an online scale operation, not a rebuild.

The trap: DTU tiers and vCore tiers use overlapping words with different meanings. Premium is a DTU tier; Business Critical is the vCore tier with the equivalent architecture. Standard (DTU) roughly corresponds to General Purpose (vCore). If a document says "Premium" without saying which model, ask.

The service tiers — the most consequential choice on this page

The tier is not a speed setting. It selects a different storage and replication architecture, and Architecture traces each one. Summarised:

Tier (vCore)	DTU equivalent	Storage architecture	Choose it when
General Purpose	Standard	Data files in remote Azure Premium Storage; one compute replica; failover by re-attaching the files to a new replica	The default. Most workloads, most budgets. Accept higher I/O latency and a failover measured in tens of seconds
Business Critical	Premium	Local NVMe SSD attached to the compute node; a four-node Always On availability group; one secondary readable for free	Latency-sensitive OLTP, or you want a free read-scale replica and the fastest failover
Hyperscale	— (vCore only)	Decoupled: compute nodes, a log service, and page servers over remote storage with local SSD caching	Very large databases (multi-TB), fast restores regardless of size, or you need many read replicas

Two behaviours worth memorising because they surprise people:

• Hyperscale restore and backup are near-instant relative to size, because they are snapshot-based at the page-server layer rather than a full-file copy. That is often the reason to choose it, more than the size ceiling.
• Moving into Hyperscale is straightforward; moving out of it is not — historically it has been a migration rather than a scale operation ⚠️ verify the current reverse-migration support and its constraints against current Azure docs. Treat it as a one-way door until you've confirmed otherwise.

Compute tiers: Provisioned vs. Serverless

Term	Analogy	Technical definition
Provisioned compute	A flat monthly gym membership	A fixed vCore count allocated continuously and billed per hour whether or not a query runs
Serverless compute	Pay-as-you-go by the minute, and the lights go off when the room is empty	You configure a min and max vCore range. Compute autoscales inside it and bills per vCore-second used. After a configurable auto-pause delay of inactivity, compute is deallocated and you pay for storage only
Auto-pause / auto-resume	The lights coming back on when someone walks in	Resuming is triggered by the next connection and takes on the order of seconds to a minute — the first connection after a pause will often time out unless the client retries. ⚠️ verify current resume latency against current Azure docs

The serverless traps, both common:

1. It never actually pauses. Anything that touches the database on a schedule — a monitoring query, a connection-pool keepalive, an ORM health check, a Data Factory pipeline — resets the inactivity timer. A serverless database that never pauses is more expensive than the provisioned equivalent, because the serverless vCore-second rate carries a premium.
2. The client doesn't retry. Build resume-tolerant retry into the connection logic, or your first request every morning fails.

Elastic pools

The multi-tenant SaaS answer. One hundred customer databases, each idle 95% of the time, each needing to burst occasionally. Buying compute per database means buying a hundred idle allocations.

An elastic pool buys one allocation (in eDTUs or pool vCores) shared by all databases on the server that you place in it. You additionally set a per-database min and max so one noisy tenant can't starve the rest. Databases move in and out of a pool as an online operation.

When it stops being the answer: when the databases' peaks are correlated. A pool works because peaks are staggered. If every tenant runs its month-end job on the last day of the month, the pool must be sized for the peak anyway and you have gained nothing but a shared blast radius.

Connectivity and identity vocabulary

Term	Analogy	Technical definition
Server-level firewall rule	The gate list for the whole street	IP allow-list stored in master, applied before any database is reached. Allow Azure services and resources to access this server is a checkbox that permits any Azure IP, including other tenants' — treat it as effectively public and don't use it in production
Virtual network rule	A gate list keyed on which building you came from	Allows a specific VNet subnet via a service endpoint. Traffic still uses the public endpoint address but is recognised as coming from your subnet
Private endpoint	A private corridor into the building from your own floor	A NIC in your subnet with a private IP mapped to the sqlServer sub-resource, plus a Private DNS zone (privatelink.database.windows.net) so the public hostname resolves privately. The production answer, paired with public_network_access_enabled = false
SQL authentication	A username and password on a sticky note	A login in master or a contained user in the database, with a password. Works everywhere, is the default, and is what you should be moving away from
Microsoft Entra authentication	A staff pass issued centrally	Token-based auth via Entra ID. Requires an Entra admin set on the logical server. Supports users, groups, service principals, and managed identities — the keyless production answer
Contained database user	A pass that only opens one building	A user created inside the database (CREATE USER [x] FROM EXTERNAL PROVIDER) with no corresponding server login. Portable across failover and required for managed-identity access
Connection policy	Whether the receptionist walks you to the room or just points	Redirect (lower latency, connects straight to the node, needs ports 11000–11999 open) vs. Proxy (all traffic through the gateway on 1433). Default picks based on where the client is. Redirect is faster; Proxy is friendlier to restrictive firewalls

Data-protection vocabulary

Term	Analogy	Technical definition
TDE (Transparent Data Encryption)	The safe the files sit in	Encryption at rest, on by default. Uses a platform-managed key unless you configure a customer-managed key in Key Vault (BYOK)
Always Encrypted	The contents are in code even to the safe's owner	Client-side column encryption where the key never reaches the service. Protects against a privileged DBA or a compromised platform, at the cost of severe query restrictions on encrypted columns
Dynamic data masking	A redaction pen over the printout	A presentation-layer mask on query results for non-privileged users. Not an encryption or authorisation control — the underlying data is intact and reachable by inference
Point-in-time restore (PITR)	Rewinding the tape	Restore to any second inside the retention window. Always restores to a new database — it is never an in-place undo, which is exactly what you want at 2 a.m.
Long-term retention (LTR)	The archive box in the basement	Weekly/monthly/yearly backup copies kept for up to a decade ⚠️ verify current maximum, billed separately, restored as a new database
Active geo-replication	A live copy of the ledger in another city	Asynchronous readable secondaries in other regions, failed over manually per database
Failover group	An automatic switchboard for that copy	A grouping over one or more databases with a listener endpoint (<name>.database.windows.net that follows the primary) and optional automatic failover. This is what applications should connect to, because it means the connection string survives a regional failover

The SKU axis, summarised

If you remember one table from this page:

Purchasing model (vCore | DTU) × service tier (General Purpose | Business Critical | Hyperscale) × compute tier (Provisioned | Serverless) × hardware family (standard-series, premium-series, and so on) × deployment shape (single database | elastic pool).

The traps, named:

• DTU Basic looks cheap and has a hard, small size ceiling and low IOPS. It is a learning tier.
• Serverless that never pauses costs more than provisioned. Check actual pause hours before celebrating.
• Business Critical chosen "for safety" can be several times the cost of General Purpose for a workload that never needed local SSD latency. Zone-redundant General Purpose is often the better resilience answer per pound.
• Hyperscale is not just "big General Purpose" — the architecture differs, some features behave differently, and coming back out is hard.

What you should be able to do now

Read any Azure SQL pricing page, sizing recommendation, or portal blade and know exactly which of the five axes above each number belongs to — and spot when someone has said "Premium" without saying which purchasing model they mean.

---

Next: Architecture →

← Back to the Azure SQL Database overview · ← Previous: What & Why