Azure SQL Database compute choice: single database vs elastic pool vs serverless
Verdict: Use elastic pool when several databases have offsetting peak usage times, spreading cost across shared resources. Use serverless for a single database with intermittent, unpredictable load, paying for actual usage. Provisioned single database suits steady, predictable workloads.
| Criterion | Single database | Elastic pool | Serverless |
|---|---|---|---|
| Resource model | Dedicated resources on one logical server | Shared pool of memory, storage, and processing power across several databases | Compute automatically allocated or deallocated as required |
| Billing basis | Charged hourly for requested capacity whether or not the database is active | Databases in the pool split the cost of the shared capacity | Billed for what the database actually uses |
| Best fit | A new, cloud-born application with one steady, predictable workload | Many databases with usage that peaks at different times, such as a multitenant SaaS estate | Intermittent or unpredictable workloads, for example dev or reporting databases idle most of the day |
Rules
- An elastic pool shares memory, storage, and processing power across multiple databases, releasing resources once each peak workload completes and reducing cost for variable-usage databases.
- Elastic pool is the cost-effective fit for a multitenant SaaS pattern, where each tenant gets its own database but usage varies over time.
- Serverless scales compute automatically, allocating or deallocating resources as required, so billing follows actual usage instead of preallocated idle capacity.
- Hyperscale is a separate service tier for very large databases with rapid on-demand scaling and fast backup and restore; it is not part of the single database vs elastic pool vs serverless compute choice.
Traps
- The default Single Database configuration preallocates resources and bills hourly for what was requested, even when the database is idle; it is not the auto-scaling, usage-billed option.
- A single database dedicates resources to one database on a logical server, so it cannot share a common resource pool across databases with differing peak times.
- Managed Instance targets lift-and-shift migration of on-premises SQL Server, not the cost-sharing of many small, variable-usage tenant databases.
- Serverless auto-scales and pauses on idle; it is not the tier for very large databases, which is Hyperscale.