1. What and Why
Before any syntax, the decision. This page answers three questions: what the service actually is, which of the four plausible alternatives you should have picked instead, and when the answer is "don't use this at all".
One sentence
Azure SQL Database is a fully managed, regional, relational database service that runs the SQL Server engine and sells you a database — not a server, not a VM — with backups, patching, and high availability built into the price of the tier you choose.
Everything interesting about it descends from that one word: database. Azure gives you the unit of
data, not the unit of machinery. You will not RDP into anything, you will not see a .mdf file, and
you will not schedule a maintenance window. In exchange, a whole category of instance-level SQL
Server features is simply not there.
The problem before it existed
Running a production relational database used to mean owning a stack of chores that had nothing to do with your application:
- Provision and size a machine, then discover a year later it was wrong in both directions.
- Install and patch the engine and the OS underneath it, on someone's Saturday.
- Configure high availability — a failover cluster instance or an Always On availability group, a quorum witness, and a runbook nobody has ever rehearsed under pressure.
- Take backups, and prove they restore. The second half is the one that gets skipped.
- Watch for the disk filling up, because a full transaction log stops the application dead.
The analogy that carries: a VM-hosted SQL Server is a car you own — insurance, MOT, tyres, parking. Azure SQL Database is a car you rent by the hour with all of that included, and the price list is just "how fast does it need to go". You never open the bonnet. That's the deal in both directions: no maintenance, and no access to the engine.
Concretely, the managed service gives you, without configuration:
- Continuous backups with point-in-time restore inside a retention window, plus optional long-term retention for compliance ⚠️ verify current default and maximum retention against current Azure docs.
- Automatic patching of the engine and the platform.
- Built-in high availability — the mechanism differs sharply by tier, which is the subject of Architecture.
- Automatic tuning — index recommendations and plan-regression correction that the platform can apply for you.
- Threat detection and auditing as configuration, not as a project.
[Image Prompt: 2D minimalistic diagram showing Azure SQL Database in the middle, with upstream callers — a web app, an API, a background worker, and a data pipeline — on the left, and downstream platform-managed responsibilities — automated backups, patching, high availability replicas, and monitoring — drawn as a managed boundary on the right, flat design, clean vector art style, white background]
Where it sits: choosing inside the Azure SQL family
This is the decision people get wrong, and it is expensive to get wrong because migrating between the options is a project. Three products share the SQL Server engine:
| Azure SQL Database | SQL Managed Instance | SQL Server on Azure VM | |
|---|---|---|---|
| You get | A database | An instance | A machine |
| Compatibility | Database-scoped features only | Near-full instance surface | Everything |
| SQL Agent | No (use Elastic Jobs, Logic Apps, or a Function) | Yes | Yes |
| Cross-database queries | No (elastic query is limited and separate) | Yes | Yes |
| Deploys into your VNet | Via private endpoint | Natively, subnet-delegated | Natively |
| Patching | Platform | Platform, with a maintenance window | You |
| Cost floor | Lowest (serverless can pause) | Highest of the three at small scale | Depends on the VM |
| Provisioning time | Minutes | Tens of minutes to hours ⚠️ verify | Minutes |
| Best for | New apps, SaaS, modernisation | Lift-and-shift of an estate | Version pinning, full control |
The one-line rule: if the application only ever says USE MyDatabase, use Azure SQL Database. The
moment it says USE msdb, joins across two databases, or creates a SQL Agent job, you are looking at
Managed Instance.
The non-SQL-Server neighbours, for completeness:
- Azure Database for PostgreSQL — Flexible Server — same bargain, different engine. Pick on engine and team familiarity; both are good.
- Azure Cosmos DB — pick it for a genuinely non-relational access pattern or multi-region writes, not because it appears in the same catalogue category.
- Azure Synapse dedicated SQL pool / Microsoft Fabric warehouse — analytics. It speaks T-SQL and that is where the resemblance stops; the storage is columnar and the execution is MPP.
The AWS analogue, and where it breaks
Closest analogue: Amazon RDS for SQL Server. The bargain is the same — managed backups, managed patching, managed failover. Four things break the analogy, and each one has bitten someone:
- RDS gives you an instance; Azure SQL Database gives you a database. In RDS you provision an instance class and create databases inside it that share its CPU and memory. In Azure, each database has its own compute allocation, and the "server" above it is a free logical container. Sharing compute between databases is an explicit opt-in called an elastic pool.
- There is no
masteryou can use. The logical server has amasterdatabase, but it is a catalog view surface for logins and firewall rules — you cannot store objects in it, and you cannot query across databases from it. - Sizing is a tier and a purchasing model, not an instance class.
db.m5.xlargemaps to a CPU and RAM pair.GP_Gen5_4maps to four vCores of General Purpose architecture — remote storage, one replica. The tier chooses your storage engine, not just your speed. - Multi-AZ is not a checkbox with the same meaning. RDS Multi-AZ is a standby in another AZ. Azure's equivalent depends on tier: General Purpose zone redundancy, Business Critical's four-node availability group, and Hyperscale's page-server model all behave differently on failover time and on read scale-out.
Carry one sentence forward: in AWS you size a server and put databases in it; in Azure you size a database and the server is a name.
When NOT to use it
- The application depends on instance-level SQL Server features. SQL Agent, linked servers,
Service Broker, CLR assemblies, cross-database transactions,
xp_cmdshell, filestream, trace flags. Every one of these is a Managed Instance signal. Don't plan to "work around it" — the workarounds accumulate into a second system. - The workload is analytical. Full table scans and large aggregations over a row store will cost you far more here than in a warehouse, and you will be tempted to over-provision compute to hide it. Columnstore indexes help, but the right answer is usually a different service.
- You need writes in more than one region simultaneously. Failover groups give you one writable primary and readable secondaries. Multi-write is Cosmos DB territory.
- The database must live inside a VNet with a private IP as a first-class citizen and you can't use private endpoints. Azure SQL Database is a public-endpoint service you lock down with private endpoints and firewall rules. Managed Instance is a VNet-native service. That difference matters to some compliance teams.
- You're migrating a heavily-customised estate and calling it "lift and shift". It won't be a lift. Run the Data Migration Assistant first; it will tell you honestly which features block you.
- Latency-critical workloads where you assumed managed meant fast. General Purpose puts data files in remote storage. If you need local-NVMe latency, that is Business Critical, at a very different price — see Architecture.
What you should be able to do now
Explain to a colleague, in under a minute, why "we'll just move our SQL Server to Azure SQL Database" is a question and not a plan — and which two facts about their application decide the answer.
Next: Core Concepts →