Free tools Windows power users keep installed
One-click scans. No signup required.
An Azure SQL elastic pool lets multiple Azure SQL Database databases share a pool of compute resources instead of each database being provisioned for its own peak. It can suit databases whose demand fluctuates or peaks at different times, but it is not automatically cheaper: compare the pool’s capacity and cost with your databases’ actual workloads.
What is an Azure SQL elastic pool?
An elastic pool is a resource-sharing option for databases in the Azure SQL Database service. You select capacity for the pool, and its member databases draw from that shared capacity as workloads rise and fall. This can avoid provisioning every database for a peak that does not happen at the same time across the group.
Sharing does not mean every database can use its configured maximum simultaneously. Pool capacity is finite, and the purchasing model and service tier determine the available limits and controls.
When should you use an elastic pool?
Evaluate a pool when you have multiple databases with variable demand, especially when their peaks occur at different times. The sharing model is less compelling if databases routinely peak together, require strong isolation, or need more capacity than the pool can provide.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
- Good candidate: a group of databases with uneven, non-overlapping bursts and enough aggregate pool headroom.
- Needs careful sizing: workloads with concurrent peaks, high concurrency, or strict performance expectations.
- May not fit: a single database, or workloads that need independently reserved capacity that shared resources cannot reliably provide.
Before choosing, compare representative workload patterns, required features and service tier, storage needs, database-level controls, backup usage, licensing eligibility, and estimated costs. Microsoft’s documentation explains configuration and billing mechanics; it does not establish a universal utilization level or break-even point at which pooling is always advantageous.
DTU vs. vCore elastic pools
Azure SQL Database offers DTU and vCore purchasing models. DTU bundles compute and storage into predefined packages; in elastic pools, compute capacity is expressed in eDTUs. The vCore model provides more direct choices for compute and storage and supports provisioned and serverless options in supported configurations. Features and limits depend on the selected tier and configuration.
| Consideration | DTU pool | vCore pool |
|---|---|---|
| How compute is expressed | eDTUs, with tier-specific packages | vCores, with configuration-dependent resource limits |
| Resource selection | Bundled compute and storage choices | Compute and storage can be selected more independently |
| Compute options | Use the available DTU tier and pool configurations | Provisioned and serverless options are available in supported configurations |
| Cost comparison | Compare the selected package and tier-specific storage rules against your baseline | Include pool compute, I/O, data and log storage, and per-database backup storage |
For eligible SQL Server licensing scenarios, Azure Hybrid Benefit may be an option in the vCore model; eligibility and savings depend on the deployment and licensing situation. For official descriptions of the models, see Microsoft’s Azure SQL Database purchasing models and DTU-based purchasing model documentation.
How pool capacity and database limits work
vCore pools
In a vCore pool, optional minimum and maximum vCore settings can shape database resource consumption. Microsoft Learn says: “For each elastic pool, you can optionally specify per database minimum and maximum vCores to modify resource consumption patterns within the pool.” The configured per-database minimum and maximum settings are common across the pool’s databases rather than independently customized for each database; maximum storage per database can be configured independently.
A configured maximum is not a guarantee that every database can reach that level at once. If all pool vCores are busy, databases receive fair shares of compute time, alongside resources guaranteed by any nonzero minimum. Resource limits also vary by service tier and hardware generation. Check the current table for the specific General Purpose, Business Critical, or Hyperscale configuration you plan to use in Microsoft’s vCore elastic pool resource limits.
DTU pools
DTU pool limits depend on the pool’s tier and size, including eDTUs, storage, per-database DTU choices, and maximum database count. Microsoft Learn’s documented limits list up to 500 databases for Basic and Standard DTU pools and up to 100 for Premium DTU pools; these are tier-dependent maxima, not a universal limit for every configuration. Some larger Premium storage configurations also have regional limits. Consult the current DTU elastic pool resource limits table before sizing or relying on a maximum.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How Azure SQL elastic pool pricing works
There is no reliable generic claim that a pool saves money. For vCore pools, Microsoft bills compute, I/O, and data and log storage at the pool level; automated backup storage is charged per database. Service tier, hardware, compute, reserved storage, and backup use affect the total. DTU pools use bundled compute packages, with storage rules that vary by tier.
Compare a proposed pool against the cost of running the databases independently using representative demand rather than peak figures alone. Include headroom for simultaneous bursts, storage, backup retention and consumption, and any licensing benefit for which you qualify. Check Microsoft’s purchasing-model and billing guidance alongside current geography-specific pricing; prices can vary by region and change over time.
Quick Recap
Best Value
A practical decision checklist
- Group databases with compatible service-tier, feature, and performance requirements.
- Review demand over time to see whether peaks are staggered or tend to coincide.
- Choose whether DTU’s bundled eDTU capacity or vCore’s more direct resource choices better match how you want to size and manage the pool.
- Check the current resource-limit table for the exact tier, pool size, hardware, and region.
- Set database-level minimums, maximums, or storage limits where available, and account for contention when multiple databases are active.
- Estimate pool and independent-database costs using current regional rates, including storage, backups, and applicable licensing.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
