Post applies to:
SQL Server	Azure SQL VM	SQL DB Singleton	SQL DB Managed Instance	Synapse (SQL DW)

Since Sep-19 a number of new flavours of Azure SQL DB have been brought on-line. So assuming you’re familiar with the fundamental capability differences between Azure SQL DB Singleton & Managed Instance (if not check our this post on the Azure SQL DB base flavors) here’s a quick summary of the different flavours and when you should consider using them.

	WHAT IS IT?	WHEN TO USE IT?
Elastic Pool	Same contained DB functionality as Singleton DB. Resources (vCores & RAM) are configured on a per DB basis when created or after at the server level. But those resources are shared with all DBs in the Elastic Pool.	Good for several smaller, lumpy-workload DBs. DBs can be moved in/out of the Pool
Hyperscale	New capacity option available to contained Singleton DB. “Bottomless SQL DB” with auto-scaling up to 100TB (this can go higher). New log & storage architecture delivers high performance through-put & near instant backup/restore	For very large/fast growing DBs. Slightly more expensive than General Purpose but far greater scalability due to storage re-architecting
Serverless	New capacity option available to contained Singleton DB. Min/max vCores & RAM set at DB creation. Auto-pause timeout also configurable. DB auto-restarts with activity. When auto-paused only storage is charged. Min/max auto-pause settings can be changed online.	Good for lumpy workloads where DB has periods of low/no activity. Restart takes approx. 1min
Instance Pool	New capacity option for SQL DB Managed Instance. Allows multiple Instances to be created sharing the MI resources. Behaves like an on-prem server with pinned resources per instance e.g. Create SQL MI with 8 vCores as a Pool then create 1×4 vCore & 2×2 vCore instances with multiple DBs on each.	Use for smaller SQL instances that don’t need 4vCores. Child Instance creation is very fast (approx. 5mins). Good for multi-tenant systems