3.1 Azure SQL Family Overview

The Azure SQL Family

Quick Answer: The Azure SQL family is Microsoft's set of cloud database services that all run the SQL Server database engine. The four members are Azure SQL Database (PaaS, single database or elastic pool), Azure SQL Managed Instance (PaaS, full SQL Server instance), SQL Server on Azure Virtual Machines (IaaS), and Azure SQL Edge (small-footprint engine for IoT and edge devices). Pick PaaS for least operational work, IaaS for full OS control, and Managed Instance when you need near-100% SQL Server compatibility.

On the DP-900 exam, every relational scenario starts with the same question: which deployment option in the Azure SQL family fits this workload? You will not be asked to write production code, but you must match a business requirement to one of these four services.

The Four Members of the Family

Azure SQL Database is a fully managed Platform-as-a-Service (PaaS) offering. Microsoft runs the operating system, patches the SQL engine, takes automated backups, and provides built-in high availability with a 99.99% SLA. You manage the database, schema, and queries. It is the best default for new cloud-native applications and supports a single database or an elastic pool that shares resources across many databases.

Azure SQL Managed Instance is also PaaS but provides a full SQL Server instance rather than a single database. It supports instance-level features such as SQL Server Agent, cross-database queries, CLR, Service Broker, linked servers, and Database Mail, giving near-100% compatibility with on-premises SQL Server. It is deployed inside a virtual network for private connectivity. Use it for lift-and-shift migrations of legacy SQL Server estates.

SQL Server on Azure Virtual Machines is Infrastructure-as-a-Service (IaaS). You install or choose a Marketplace image with SQL Server on Windows or Linux, and Microsoft only manages the underlying hardware and hypervisor. You are responsible for patching the OS, configuring SQL Server, scheduling backups, and tuning high availability. This option gives the most control and is required when an application depends on OS-level features like FILESTREAM, third-party agents, or a specific SQL Server build.

Azure SQL Edge is a small-footprint version of the SQL engine that runs in a container on ARM and x64 edge devices. It supports a subset of T-SQL plus built-in streaming and time-series capabilities. It is aimed at Internet of Things (IoT) scenarios where data must be processed locally before being synced to the cloud.

Deployment Model Comparison

How to Pick One

• Choose Azure SQL Database when you build a new application, need fast provisioning, and do not depend on SQL Agent jobs, cross-database transactions, or linked servers.
• Choose Azure SQL Managed Instance when you migrate an existing SQL Server database that uses SQL Server Agent, CLR, linked servers, or three-part cross-database queries.
• Choose SQL Server on Azure VMs when you need a specific SQL Server build, OS-level access, FILESTREAM with file system semantics, or third-party agents installed on the host.
• Choose Azure SQL Edge for IoT gateways and edge workloads that need lightweight SQL plus stream processing close to the data source.

Shared Foundations

Despite the deployment differences, every option in the family uses the same SQL Server database engine, supports standard T-SQL, and can be managed with SQL Server Management Studio (SSMS), Azure Data Studio, the Azure CLI, PowerShell, and ARM/Bicep templates. Your T-SQL knowledge transfers across the entire family, which is exactly why Microsoft groups them as one product line.

The Shared Responsibility Spectrum

The single most useful way to remember the family is as a management spectrum from "Microsoft does almost everything" to "you do almost everything." Azure SQL Database (single database) sits at the managed end: Microsoft handles the OS, the engine, patching, backups, and high availability. SQL Managed Instance is slightly less abstracted (you manage instance-level config and a VNet).

SQL Server on Azure VMs sits at the control end: you own the OS and engine patching, and Microsoft only manages the hypervisor and hardware. As you move toward IaaS you gain control and compatibility but take on operational work; as you move toward PaaS you shed work but lose some instance-level features.

SQL Database: Single Database vs Elastic Pool

Azure SQL Database has two deployment shapes. A single database has its own dedicated, independently scalable resources — ideal for one application with steady needs. An elastic pool is a shared pot of resources (DTUs or vCores) that many databases draw from; databases that are quiet lend capacity to databases that are busy. Elastic pools shine for multi-tenant SaaS where each tenant has a database but few peak at the same moment, lowering the total bill versus provisioning every database for its own peak.

Migration Decision Flow

A recurring exam pattern asks you to choose a target for an on-premises SQL Server migration. The decision flow is: (1) Does the app depend on instance-level features — SQL Agent jobs, cross-database queries, CLR, Service Broker, linked servers? If yes, choose Managed Instance. (2) Does it also need OS-level access, a specific SQL build, FILESTREAM with file-system semantics, or third-party host agents? If yes, choose SQL Server on Azure VMs.

(3) If it is a modern, self-contained database with none of those dependencies, choose Azure SQL Database. Working that flow in order is the fastest way to answer family-selection questions.

What Stays the Same

No matter which member you choose, you write the same T-SQL, use the same drivers (ADO.NET, JDBC, ODBC, the SQL Server Python/Node libraries), and administer with the same tools (SSMS, Azure Data Studio, sqlcmd). This portability is the entire point of grouping them as one family and is why migrating between members rarely requires rewriting application queries.