Azure SQL elastic pools cost: sharing capacity across databases

Quick answer

An Azure SQL elastic pool shares one pool of compute (DTUs or vCores) across many databases, so instead of paying for each database's peak separately you pay once for the pool's aggregate capacity. When databases have staggered, non-overlapping peaks, this is dramatically cheaper: a 100 eDTU pool at about $220 per month can host dozens of small databases that would each cost $15 or more as single Standard S0 databases. The rule is pool databases whose peaks do not coincide, and keep isolated always-busy databases on their own where a dedicated allocation is cheaper.

Many organizations run fleets of small Azure SQL databases, one per tenant, per microservice, or per environment. Provisioning each on its own compute means paying for each database's peak capacity even though most sit idle most of the time. Elastic pools solve this by letting all the databases share a single pool of compute, so you buy for the aggregate rather than the sum of the peaks.

How pool pricing works

Option	Billing basis	Best for
Single database	Per database's own DTU/vCore	One busy database
Elastic pool	Shared pool of eDTU/vCore	Many databases, staggered peaks

A pool is billed for its total allocated capacity, measured in eDTUs (elastic DTUs) or pooled vCores, not per database. A 100 eDTU Standard pool runs roughly $220 per month and can host up to hundreds of databases, each drawing from the shared pool as needed. Because you pay once for the pool, adding another small database costs nothing until the aggregate load forces you to grow the pool.

Why staggered peaks are the key

The savings depend entirely on databases not all peaking at once. If ten databases each need 10 DTUs at their peak but those peaks happen at different times, a single 100 eDTU pool covers them all, because the sum of their simultaneous demand rarely approaches 100. Provisioned individually at 10 DTUs each, they would cost far more and still waste capacity when idle. If all ten peaked at the same moment, the pool would need 100 eDTUs of headroom anyway and the advantage would shrink. So the pool wins precisely when demand is spread out.

A concrete comparison

Suppose you run 30 tenant databases, each lightly used. As single Standard S0 databases at 10 DTUs, that is roughly 30 times $15, about $450 per month. Placed in a single 100 eDTU pool at about $220 per month, the same 30 databases cost less than half, because their small, staggered loads comfortably fit the shared 100 eDTUs. The more databases you pool, the larger the saving, up to the pool's per-database limits.

When a pool does not help

Pools are the wrong tool for a single database that is busy on its own; that database should have its own provisioned or serverless allocation, sized as in the serverless cost guide. Pools also do not help when every database in the group is heavily and simultaneously loaded, since the pool must then be sized for the combined peak. And within the vCore model, a reservation on pool compute cuts the rate further, the same commitment logic as the Azure reservations guide.

Sizing the pool

Start by measuring each database's DTU or vCore usage over time, sum the simultaneous demand rather than the individual peaks, and size the pool to cover the aggregate peak with modest headroom. Monitor pool utilization and grow or shrink it as the fleet changes. Price the pool against the resource catalog before you deploy so the choice between individual databases and a shared pool is a clear cost comparison rather than a guess.

FAQ

What is an Azure SQL elastic pool?

It is a shared pool of compute, measured in eDTUs or pooled vCores, that many databases draw from as needed, instead of each database having its own dedicated allocation. You are billed for the pool's total capacity rather than per database, so adding another small database costs nothing until the aggregate load forces the pool to grow. It suits fleets of small databases with staggered peaks.

When does an elastic pool save money?

When you have many databases whose peaks do not coincide. Ten databases each needing 10 DTUs at different times fit comfortably in a single 100 eDTU pool at about $220 per month, versus far more provisioned individually. The saving grows with the number of pooled databases. If all databases peaked simultaneously, the pool would need to be sized for the combined peak and the advantage would shrink.

How much can an elastic pool save versus single databases?

For a fleet of lightly used databases, often more than half. Thirty Standard S0 databases at 10 DTUs cost roughly $450 per month provisioned individually, but the same thirty in a 100 eDTU pool cost about $220 because their small, staggered loads fit the shared capacity. The more databases you consolidate into a well-sized pool, the larger the proportional saving.

When should I not use an elastic pool?

When you have a single database that is busy on its own, which should have its own provisioned or serverless allocation rather than a pool, and when every database in the group is heavily and simultaneously loaded, since the pool must then be sized for the combined peak and offers little advantage. Pools help specifically when demand is spread across many databases over time.

How does C3X help with elastic pool cost?

C3X prices Azure SQL configurations from Terraform before you deploy, so the cost of an elastic pool versus a set of single databases is visible in the pull request. That lets you compare the shared-pool approach against individual allocations for your database fleet at design time and size the pool correctly before the databases are running.

What to do next

Compare elastic pools and single databases before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.