Why SQL Deployment Options Matter
SQL Server is one of the most widely used databases in enterprises. Azure provides multiple ways to run SQL depending on control, flexibility, and modernization goals.
As a Solution Architect, your role is to recommend the right option based on requirements such as compatibility, scalability, management overhead, and cost.
Azure SQL Deployment Options
1. Azure SQL Database (Single Database / Elastic Pool)
-
Type: Fully managed Platform-as-a-Service (PaaS).
-
Use Cases: Cloud-native apps, SaaS workloads, new projects.
-
Key Features:
-
Microsoft handles patching, backups, HA.
-
Automatic scaling (DTU or vCore model).
-
Built-in HA (99.99% SLA).
-
Elastic Pools allow multiple databases to share resources.
-
When to Choose:
-
Applications that don’t need full SQL Server features.
-
When minimizing management is a priority.
-
For modern, cloud-first apps.
2. Azure SQL Managed Instance (MI)
-
Type: PaaS but with near-full SQL Server compatibility.
-
Use Cases: Lift-and-shift SQL workloads to Azure without major refactoring.
-
Key Features:
-
Supports SQL Agent, linked servers, Service Broker.
-
Native VNET support for better isolation.
-
Auto backups and patching.
-
Can scale to large workloads.
-
When to Choose:
-
For applications needing on-prem SQL Server features.
-
Migration scenarios where refactoring is expensive.
-
Hybrid scenarios needing VNET integration.
3. SQL Server on Azure VMs (IaaS)
-
Type: Infrastructure-as-a-Service (full SQL Server installed on VM).
-
Use Cases: Legacy apps needing OS-level or SQL Server customizations.
-
Key Features:
-
Full control (you manage OS, patches, backups, HA).
-
Supports all SQL Server features.
-
High admin overhead.
-
When to Choose:
-
For legacy workloads that require complete control.
-
When SQL features not supported in PaaS are required.
-
As a temporary solution before migrating to PaaS.
Comparison Table
| Feature | SQL Database | Managed Instance | SQL on VM |
|---|---|---|---|
| Type | PaaS (modern apps) | PaaS (near full compat) | IaaS (legacy lift) |
| Management | Fully managed | Microsoft-managed | Self-managed |
| Compatibility | Limited | High (close to full) | Full |
| Scaling | Easy, elastic pools | Large, flexible | VM sizing only |
| Network Integration | Public endpoint | VNET support | Full VM control |
| Best Use Case | Cloud-native apps | Lift-and-shift SQL | Legacy workloads |
Example Enterprise Scenario
A retail company has three different workloads:
-
A new e-commerce app → cloud-native, needs minimal overhead.
-
A line-of-business app running SQL Agent jobs → requires compatibility.
-
A legacy ERP system → highly customized SQL configuration.
Correct design:
-
Azure SQL Database for e-commerce.
-
Managed Instance for the line-of-business app.
-
SQL on Azure VM for the ERP system.
Confusion Buster
-
SQL Database ≠ Managed Instance.
-
SQL Database → modernized, least admin overhead.
-
Managed Instance → hybrid/lift-and-shift with compatibility.
-
SQL on VMs → full control but most overhead.
Exam Tips
-
“Which option for cloud-native SaaS?” → Azure SQL Database.
-
“Which option for migrating SQL Server with minimal changes?” → Managed Instance.
-
“Which option provides full control of OS and SQL configuration?” → SQL on VMs.
-
“Which option allows resource sharing across multiple DBs?” → Elastic Pool in SQL Database.
What to Expect in the Exam
-
Direct Q: “Which Azure SQL option is closest to on-prem SQL Server?” → Managed Instance.
-
Scenario Q: “Company wants minimal admin overhead for new SaaS.” → SQL Database.
-
Scenario Q: “Legacy system requires SQL CLR and linked servers.” → SQL on VM.
-
Trick Q: “SQL Database supports all on-prem SQL Server features.” → False.