# Azure SQL Elastic Pool

> SQL elastic pools reserve a fixed allocation of eDTUs or vCores shared by member databases, billing for that capacity 24/7 even when every member is quiet. ZopNight reads pool sizing via Resource Graph, tracks 60 days of pool utilization, and flags over-provisioned pools plus servers whose standalone databases would consolidate well.

Source: https://zop.dev/integrations/azure/sql-elastic-pool
Updated: 2026-08-19

---

SQL elastic pools share a fixed allocation of compute resources across many databases with variable usage. A pool sized for peak load bills for that capacity constantly, even when member databases are quiet.

## eDTUs and vCores are reserved at the pool, not the database

An elastic pool moves the meter up a level: member databases stop billing individually and the pool bills for its full reserved allocation (eDTUs on the DTU model, vCores on the newer one) around the clock. The economics work when many databases with staggered peaks share headroom; they invert when a pool is sized for a peak that arrives rarely, because the reservation bills at 100 percent while utilization sits far below it. Pools also cannot be paused, so unlike a Serverless database the meter never dips on its own.

## Pool telemetry ZopNight works from

Discovered via Azure Resource Graph with pool sizing. Azure Monitor metrics with a 60-day lookback show pool-level utilization, Cost Management billing attributes spend, and rightsizing recommendations flag over-provisioned pools.

## The consolidation check on standalone siblings

Pools cut both ways, so ZopNight also evaluates the opposite move: its consolidation rule lists the poolable standalone databases on each logical server, excluding master and databases already in a pool, and considers consolidation only when a server has at least 2 poolable siblings. The sibling list is deliberately capped at 100 databases, the Basic and Standard pool maximum (Premium allows 500); beyond that the rule stays silent rather than mis-pricing the saving, since consolidating a server that large is a capacity decision, not an automated one.

## How elastic pools overspend

Three patterns dominate: pools provisioned at launch for growth that never came; pools kept at peak size after their busiest members were migrated out; and single-database pools, which pay the pooling premium for sharing that cannot happen.

## Reviewing pools in the portal

Azure portal → SQL elastic pools lists each pool with its server and configured size. A pool's blade charts its resource utilization, which is the fastest visual check on whether the reserved allocation matches what members actually draw.