Choose Your Azure SQL Platform
Azure SQL Database, Managed Instance, or SQL Server on VMs? Learn when to use each platform, plus Arc-enabled SQL, Azure SQL in Fabric, sharding, and partitioning strategies.
The Azure SQL family
Think of Azure SQL like choosing a car.
Azure SQL Database is like a taxi — you just tell it where to go. No engine maintenance, no insurance paperwork. Microsoft handles everything under the bonnet. Perfect when you want to focus on your data, not the infrastructure.
Azure SQL Managed Instance is like a chauffeured company car — you pick the model and set some rules, but someone else does most of the driving. You get features that feel like your old SQL Server (Agent jobs, cross-database queries), without managing the OS.
SQL Server on Azure VMs is like buying your own car in a new city — full control, your rules, your schedule. You manage the engine, the tyres, and the oil changes. Best when you need features that only a full SQL Server installation provides.
The big comparison
This table is the single most important thing in your DP-300 preparation. The exam constantly asks “which platform for this scenario?”
| Feature | SQL Database | Managed Instance | SQL on VMs |
|---|---|---|---|
| Management model | PaaS (fully managed) | PaaS (instance-level) | IaaS (you manage OS + SQL) |
| SQL Server Agent | No (use elastic jobs) | Yes | Yes |
| Cross-database queries | No (within elastic pools only) | Yes | Yes |
| Linked servers | No | Yes | Yes |
| Database Mail | No | Yes | Yes |
| CLR integration | Limited | Yes | Yes |
| FILESTREAM / FileTable | No | No | Yes |
| SSRS / SSIS / SSAS | No | No (MI can host SSRS catalog) | Yes |
| OS access | No | No | Yes (full RDP) |
| Patching | Automatic | Automatic | Manual or Azure Update Manager |
| HA built-in | Yes (99.99% SLA) | Yes (99.99% SLA) | You configure (AGs, FCIs) |
| Backups | Automated (PITR 1-35 days) | Automated (PITR 1-35 days) | Manual or automated via extension |
| Max database size | 100 TB (Hyperscale) | 16 TB | Per disk (256 TB+) |
| Elastic pools | Yes | Yes (instance pools) | No |
| Serverless compute | Yes | No | No |
| Cost model | DTU or vCore | vCore only | Pay-as-you-go or AHUB |
| Best for | New cloud apps, SaaS, microservices | Lift-and-shift from on-prem SQL Server | Full control, legacy apps, third-party tools |
Exam tip: The decision shortcut
On the exam, listen for these keywords in the scenario:
- “SQL Server Agent” or “cross-database queries” → Managed Instance
- “FILESTREAM” or “SSRS on the same server” or “third-party software” → SQL on VMs
- “serverless” or “elastic pool” or “auto-scale” → SQL Database
- “lift and shift” + “minimal changes” → Managed Instance
- “full OS control” or “custom patching schedule” → SQL on VMs
Choosing the right platform — scenario walkthrough
Let’s see how our characters would choose:
Kenji (NorthStar Logistics) has 200+ databases on SQL Server 2019. Many use SQL Server Agent jobs, linked servers, and cross-database queries. He needs near-100% compatibility with minimal code changes. → Azure SQL Managed Instance — it supports Agent, linked servers, and cross-database queries out of the box.
Priya (ScaleWave) is building a multi-tenant SaaS app. Each customer gets their own database. She needs auto-scaling and wants to share resources across tenants. → Azure SQL Database with elastic pools — serverless + elastic pools handle multi-tenant scaling perfectly.
Kenji again has a legacy reporting system that depends on SSRS and SSIS running on the same server as the database. No time to re-architect. → SQL Server on Azure VMs — the only option that supports all SQL Server services co-located on one machine.
Azure Arc-enabled SQL services
What is Azure Arc? It extends Azure management to SQL Server instances running anywhere — on-premises, edge locations, other clouds, even laptops in a branch office.
Why it matters for the exam:
- Azure Arc-enabled SQL Server lets you inventory, govern, and monitor on-prem SQL instances from the Azure portal
- You get Azure features like Microsoft Defender for SQL, Azure policies, and best practices assessments on your existing on-prem servers
- It does NOT move your data to Azure — it brings Azure governance to your data wherever it lives
Kenji’s use case: NorthStar has 50 SQL Server instances across three data centres. Azure Arc gives him a single pane of glass in the Azure portal to see all of them, assess their security posture, and plan which ones to migrate first.
Azure SQL Database in Microsoft Fabric
Azure SQL Database mirroring in Fabric replicates your SQL Database data into OneLake in near real-time. This gives you:
- Analytics without ETL — query your operational data in Fabric without building pipelines
- No performance impact — mirroring reads from the change feed, not your production workload
- Delta Lake format — data lands in open Delta Lake format for Spark, KQL, and Power BI
Priya’s use case: ScaleWave’s customers want real-time dashboards. Instead of building an ETL pipeline, Priya enables Fabric mirroring — customer data flows into OneLake, and Power BI Direct Lake reports update in near real-time.
Exam tip: Fabric mirroring scope
As of April 2026, Fabric mirroring works with Azure SQL Database. It does NOT support Azure SQL Managed Instance or SQL Server on Azure VMs directly. If the exam asks about analytics on MI or VM data, the answer involves other tools (like Azure Data Factory or Synapse Link), not Fabric mirroring.
Table partitioning and sharding
When your tables get very large (millions or billions of rows), you need a strategy to keep queries fast.
Partitioning divides a single table into smaller pieces within the same database:
- Based on a partition key (usually a date column)
- Queries that filter on the partition key only scan relevant partitions
- Supported on all three Azure SQL platforms
- Uses partition functions (define boundaries) and partition schemes (map to filegroups)
Sharding divides data across multiple databases:
- Each shard holds a subset of the data (e.g., customers A-M in shard 1, N-Z in shard 2)
- Used for extreme scale-out scenarios
- Azure SQL Database supports elastic database tools for sharding
- More complex to manage than partitioning
| Strategy | Scope | When to Use |
|---|---|---|
| Partitioning | Within one database | Large tables, date-range queries, partition switching for data lifecycle |
| Sharding | Across multiple databases | Extreme scale, multi-tenant isolation, geographic data distribution |
Tomas’s learning moment: His mentor Sam explains: “Partitioning is like dividing a filing cabinet into labelled drawers. Sharding is like having multiple filing cabinets in different offices — more capacity, but harder to search across all of them.”
Priya needs to deploy a multi-tenant SaaS application where each tenant gets their own database and resources are shared to save costs. Which Azure SQL offering should she recommend?
Kenji is migrating an on-premises SQL Server that uses SQL Server Agent jobs, Database Mail, and cross-database queries. Which Azure SQL platform should he choose?
Amara's healthcare org has SQL Server instances in three branch clinics. She needs to see all instances in the Azure portal for security assessment without moving any patient data to Azure. What should she deploy?
🎬 Video coming soon
Next up: Deploy and Configure Azure SQL — learn automated deployment methods, hybrid solutions, and how to keep everything patched.