Plan and Implement Data Platform Resources
Choosing a deployment target
Azure SQL has four landing spots: Azure SQL Database (single database or elastic pool), Azure SQL Managed Instance, SQL Server on Azure VMs, and Azure SQL Edge. Single databases fit well-scoped line-of-business apps; elastic pools fit many databases with spiky, non-overlapping usage; Managed Instance gives near-full SQL Server surface area (cross-database queries, SQL Agent, CLR, Service Broker) with PaaS patching; VMs give OS control and are the fallback when a feature is unsupported.
Compute and purchasing
Each option is bought in a DTU model (Basic/Standard/Premium) or a vCore model. vCore tiers are General Purpose (remote premium storage), Business Critical (local SSD, multiple replicas, memory-optimized OLTP), and Hyperscale (very large databases, fast restore from snapshots). Serverless is a General Purpose-only variant that auto-scales and can auto-pause after a configurable delay, billed per second of compute.
Traps
- DTU-to-vCore conversions are not 1:1; never size by multiplying.
- Auto-pause does not exist on Business Critical or Hyperscale, and an open connection keeps a serverless database awake.
- Every database in an elastic pool must sit on the same logical server; pools do not span servers.
- Hyperscale omits some features (for example memory-optimized tables and certain replication paths) - verify before recommending.
Rule of thumb
Need cross-database joins in one batch or SQL Agent? → Managed Instance. Need the cheapest home for dozens of small, rarely used databases? → elastic pool. Need pause-when-idle for an occasional reporting database? → serverless General Purpose.