Individual database peaks do not tell you when combined demand arrives. Azure SQL elastic pools let those databases share a resource budget, provided their combined demand fits the pool.
Start Elastic Pools With the Shape of Combined Demand
Sizing every database for its individual peak can leave substantial unused capacity between peaks. A pool can share that headroom among databases on the same logical server. The attractive case is a set of workloads whose peaks occur at different times. Sharing does not create capacity when every database becomes busy together.
Look beyond average CPU. Log generation, data I/O, workers, sessions, and storage can constrain the workload too. A pool that meets its CPU budget can still experience another limit. I compare simultaneous demand across the databases instead of adding isolated daily peak values and calling the result a realistic workload.
Collect a representative business cycle with consistent timestamps. Include scheduled maintenance, tenant onboarding, reporting, and month-end activity where relevant. A quiet hour cannot establish that a pool supports the next reporting window. The resource budget is shared; the databases do not arrange a polite meeting before using it.
Understand Elastic Pools and Per-Database Bounds
The pool has its own configured resources, and individual databases have supported minimum and maximum settings. Those per-database settings shape how resources can be allocated within the pool. Their exact behavior and valid combinations depend on the purchasing model and service configuration. Check the current limits for the proposed deployment.
A configured minimum should not be confused with constant active utilization. A maximum prevents one database from consuming beyond its permitted share, but a cap can also restrict a legitimate peak. Set bounds from the accepted workload rather than giving every database the same value merely because it is easy to administer.
Consider correlated demand before choosing the pool size. A shared application deployment can trigger work across many tenants simultaneously. An overnight job can erase the apparent separation between daytime peaks. Test those coordinated events and retain headroom for the workloads that cannot wait behind another database's maintenance activity.
Inspect the Database Service Configuration
Connect to the logical server's master database to inspect the registered database service objectives and pool membership. Then connect separately to each user database for its resource statistics. This is Azure SQL Database metadata, not a script for a locally installed SQL Server instance. On a local instance, every query in this post stops with error 208 because these views do not exist there.
SELECT d.name AS DatabaseName,s.edition,s.service_objective,
s.elastic_pool_name
FROM sys.databases AS d
JOIN sys.database_service_objectives AS s ON s.database_id=d.database_id
WHERE d.name<>N'master';Record the pool's configured resources and per-database bounds through the approved service-management view alongside this inventory. Database membership alone does not describe the entire resource policy. Keep the capture time and purchasing model with the record so a later capacity change cannot be mistaken for the original test configuration.
Verify that each database intended for the pool is actually a compatible Azure SQL Database deployment. A logical grouping in an application does not imply shared pool membership. Include the current storage footprint and growth rate when planning migration, because compute sharing does not remove storage limits.
Measure Each Database Over the Same Window
The database resource-statistics DMV provides recent interval measurements. It has short retention, so capture it repeatedly into an approved monitoring store when a longer comparison is required. The first query shows the current database's recent intervals, and the second summarizes the available window.
SELECT end_time,avg_cpu_percent,avg_data_io_percent,
avg_log_write_percent,max_worker_percent,max_session_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time;
SELECT MIN(end_time) AS WindowStartUTC,MAX(end_time) AS WindowEndUTC,
AVG(avg_cpu_percent) AS MeanCPUPercent,
MAX(avg_cpu_percent) AS PeakCPUPercent,
MAX(avg_data_io_percent) AS PeakDataIOPercent,
MAX(avg_log_write_percent) AS PeakLogWritePercent
FROM sys.dm_db_resource_stats;These percentages refer to the relevant resource limits. Do not add percentages from differently sized databases as though they were directly interchangeable units of pool capacity. Use the actual pool measurements and configuration for the combined view. Align timestamps when comparing bursts; averaging separate windows can conceal simultaneous pressure.
Capture application latency and errors with the resource metrics. A capped database can be slow while the pool still has unused capacity that its individual maximum prevents it from reaching. Conversely, several individually modest databases can collectively saturate the pool. The operating decision needs both perspectives.
Inspect the Pool's Recent Resource Use
The pool resource DMV reports recent shared utilization from a database in the pool. Query it under the documented permissions for the deployment and preserve the observation window. The following example compares the pool's compute and I/O percentages without inventing a utilization threshold.
SELECT end_time,avg_cpu_percent,avg_data_io_percent,
avg_log_write_percent
FROM sys.dm_elastic_pool_resource_stats
ORDER BY end_time;The related historical service views and approved monitoring system can support longer retention. Do not treat a missing interval as zero demand. Record collection gaps and configuration changes, then compare only windows whose scope is understood. Elastic pools need capacity planning across the shared budget, not merely a collection of healthy-looking individual charts.
Which coordinated task can make every tenant busy at once? Include that event in the acceptance test. I check the busiest shared period together with each important database's latency and resource caps. A pool that looks efficient on an average-day chart can still fail a critical synchronized task.
Test a Pool Move With Representative Work
Use a controlled trial with realistic tenant mix, peak timing, and maintenance behavior. Compare service latency, throughput, errors, resource saturation, and cost under the actual available pricing model. Avoid assuming a saving from the feature name. Pool sizing, workload shape, and reserved capacity choices determine the result.
Review the effect of changing per-database bounds during the trial. Ensure the settings preserve service expectations for critical tenants. Keep a documented reversal path and account for the service's supported move behavior. A resource change can affect active workloads and needs the same observation and acceptance process as other production capacity changes.
Separate a successful move operation from a successful workload trial. The database can join the pool while its application fails the accepted latency target. Retain measured results from normal, peak, maintenance, and failure-recovery periods before adopting the design broadly.
When a Single Database Beats Elastic Pools
A database with sustained independent demand, a large isolated peak, incompatible limits, or a strict isolation requirement can be a better fit for its own service objective. Pools work well when sharing matches the workload's demand pattern and operating constraints. They are not mandatory for every multi-database application.
Review membership as the workload grows. Move or resize an outlier through the approved capacity process when it changes the pool's behavior. Elastic pools are useful when the combined evidence supports sharing, and their settings should remain part of an active capacity review rather than a one-time migration decision.
Related reading on this blog: Azure SQL Database or Managed Instance and Azure SQL Database Wait Stats: Reading sys.dm_db_wait_stats.
A pool is not extra capacity without a limit, it is a shared resource budget that must fit simultaneous demand.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
