Azure SQL Database

Azure SQL Database is a fully managed relational database built on the SQL Server engine, sold as a logical database rather than a machine. You get a T-SQL endpoint, a backup regime, automatic patching, and a scaling dial — and you never see, name, or log into the server underneath, because there isn't one in any sense you can touch.

Names: the service is Azure SQL Database, one member of the Azure SQL family alongside Azure SQL Managed Instance and SQL Server on Azure Virtual Machines. It has picked up product names over the years that people still use interchangeably and shouldn't: SQL Azure (the original 2010 name), elastic pools, Hyperscale (a service tier, not a separate product), and Azure Synapse Analytics dedicated SQL pool (a different service — formerly SQL Data Warehouse — that shares the T-SQL surface and nothing else architecturally).

What it is and where it fits

You create a logical server (a name, an authentication configuration, and a firewall — not a machine), and inside it one or more databases. Each database is an independently sized, independently billed, independently scaled unit with its own compute allocation. You connect over TDS on port 1433 to <server>.database.windows.net, and from your application's point of view it is SQL Server: the same T-SQL, the same drivers, the same query plans, the same sys catalog views.

The problem it kills is the operational tail of running a relational database. Before it, "we need a SQL database" meant a VM, a licence, a patching window, a backup job someone has to test, a failover cluster nobody has practised, and a DBA on call. Azure SQL Database absorbs all of that: backups are continuous and point-in-time restorable by default, patching happens without you, and high availability is a property of the service tier rather than a project. What you give up is the instance — anything that lives at server scope in SQL Server (SQL Agent, cross-database queries, CLR, Service Broker, the master database as you know it) is either absent, reshaped, or replaced.

Azure's data catalogue overlaps itself, and "which SQL?" is one of the most common design arguments on the platform. The neighbours, one line each:

• Azure SQL Managed Instance — near-100% SQL Server instance compatibility, including SQL Agent, cross-database queries, linked servers, and Service Broker, deployed into your VNet. Choose it when you are lifting an existing SQL Server estate and the application depends on instance-level features. You pay for that compatibility in cost floor and provisioning time.
• SQL Server on an Azure VM — full control, full responsibility, your licence, your patching. Choose it only when you need a specific version, a specific trace flag, or filesystem access.
• Azure Database for PostgreSQL / MySQL — Flexible Server — the same managed-relational bargain for a different engine. Choose on engine, not on features; the operational stories are similar.
• Azure Cosmos DB — a different data model entirely. Choose it for global multi-write, schema-flexible documents, or single-digit-millisecond key lookups at planetary scale, not because it says "database".
• Azure Synapse / Microsoft Fabric warehouse — columnar, MPP, analytics. Choose it when the query shape is "scan a billion rows and aggregate", not "read one order by ID".

The honest summary: Azure SQL Database is the right default for a new OLTP relational workload on Azure, and the wrong default for a lift-and-shift that expects to still be an instance.

Key facts at a glance

Category	Databases — managed relational (OLTP)
Resource provider	Microsoft.Sql/servers (the logical server) and Microsoft.Sql/servers/databases
Scope	Regional. The logical server has a globally unique DNS name; the database is resource-group scoped
SKU / tier axis	Two dimensions at once: the purchasing model (vCore or DTU) and the service tier (General Purpose, Business Critical, Hyperscale; or Basic/Standard/Premium in DTU terms), plus Provisioned vs. Serverless compute within vCore
Unit of billing	Compute (vCores × hours, or DTUs) + storage GB/month + backup storage beyond the included amount. Serverless bills vCore-seconds and can pause to zero compute
SLA posture	Higher for zone-redundant Business Critical than for single-replica General Purpose; the tier is the SLA ⚠️ verify current SLA figures against current Azure docs
Usual companions	Microsoft Entra ID, Key Vault, Private Link, Azure Monitor / Log Analytics, App Service or Functions or AKS as the caller
Primary alternative	Azure SQL Managed Instance (compatibility) or PostgreSQL Flexible Server (engine choice)
AWS analogue	RDS for SQL Server — a decent analogy for the managed-database bargain, a poor one structurally, because RDS gives you an instance and Azure SQL Database gives you a database

When to use it

• New OLTP applications that want relational integrity, transactions, and a mature query optimiser without an operations team.
• Modernising a SQL Server application that talks to one database and doesn't reach across databases or into instance-level features.
• Spiky or intermittent workloads — the Serverless compute tier auto-pauses and bills nothing for compute while paused, which no other tier in the family does.
• Multi-tenant SaaS where each tenant gets a database — elastic pools exist precisely to make hundreds of small, mostly-idle databases affordable.
• Very large single databases (multi-TB) that must stay OLTP — Hyperscale decouples storage from compute and restores in minutes rather than hours, largely independent of database size.

When not to use it

• Instance-level dependencies. SQL Agent jobs, cross-database joins, linked servers, Service Broker, CLR, and msdb are the classic blockers. That's Managed Instance's whole reason to exist.
• Analytics at scale. Row-store OLTP with a warehouse-shaped query pattern will be slow and expensive. Use a warehouse, or at minimum a read replica with columnstore indexes.
• Lift-and-shift where the app expects to own the server. Anything that runs RESTORE DATABASE FROM DISK, reads a trace file, or assumes a drive letter has to change.
• Multi-region write. Active geo-replication and failover groups give you readable secondaries and a failover, not concurrent multi-region writes. If you need write-anywhere, that's Cosmos DB.
• Very small, very cost-sensitive workloads that can't tolerate any always-on charge — check the serverless auto-pause behaviour and the storage floor before assuming it is nearly free.

What this topic covers

Sub-topic	What it covers
What & Why	The problem it kills, the Azure SQL family decision, the RDS analogy and exactly where it breaks, and the honest anti-patterns
Core Concepts	Logical server, database, purchasing models, service tiers, serverless, elastic pools, DTU vs. vCore, and the SKU traps
Architecture	The General Purpose vs. Business Critical vs. Hyperscale storage architectures, the query path, control plane vs. data plane, HA and failover, and the failure modes
Getting Started	One database and one table, three ways — portal, az CLI, minimal Terraform — plus teardown
Deployment	A parameterised Terraform module, remote state, an Ansible playbook, the Bicep equivalent, OIDC-based CI/CD, schema migrations, environments, rollback, and drift
Integrations	Entra ID, Key Vault, Private Link, App Service and Functions, Data Factory, Azure Monitor, and the two glue mechanisms that recur everywhere
Production	Security, cost, scaling and quota scopes, observability, and reliability — the five pillars that separate a demo from a running system
Interview Questions	Three tiers of questions with answer keys, from "what is a DTU" to "someone scaled this in the portal, now what"
Glossary & Cheatsheet	Every term in one line each, the commands you'll actually type, the resource ID shape, and the limits worth memorising

Three ideas worth carrying into every other page

The server is not a server. Microsoft.Sql/servers is a logical container: a DNS name, an administrator identity, a firewall, an auditing configuration, and a set of Entra settings. It has no compute of its own and it is free. Compute belongs to each database (or to the elastic pool). Almost every wrong mental model of this service starts by assuming the server is a machine.

The service tier is the architecture, not a pricing row. General Purpose puts your data files in remote Azure Storage and keeps one compute replica; Business Critical keeps local NVMe and a four-replica Always On availability group; Hyperscale splits the engine into page servers and a log service. Latency, failover time, restore time, and maximum size all follow from that choice. "We use Azure SQL" tells you almost nothing until you know the tier.

Identity is where the real security work is. A SQL login with a password is the easy path and the wrong one. The production answer is a Microsoft Entra ID admin on the logical server, contained database users mapped to managed identities, and no password anywhere in configuration. Say it once here and it recurs on every page.

Resource groups, subscriptions, ARM, and RBAC inheritance are explained once in Foundations rather than repeated here.

Reading paths

New to managed databases — What & Why → Core Concepts → Getting Started. Build one, delete it, then come back for Architecture.

Coming from RDS — skim What & Why for where the analogy breaks, then read Core Concepts for the logical-server model and Architecture for the three storage architectures, which have no RDS equivalent.

Need to ship this week — Deployment first, especially the schema-migration section, then Production. Getting Started is deliberately throwaway; don't build on it.

Interview or certification prep — Core Concepts, Architecture, and Interview Questions. The tier-comparison question and the DTU-vs-vCore question come up in almost every AZ-204 and AZ-305 interview.

Chasing a cost surprise — the cost section of Production, then the serverless and elastic pool discussion in Core Concepts. An over-provisioned Business Critical database and a serverless database that never actually pauses are the two usual culprits.

---

Next: What & Why →

← Back to the article