This chapter covers Azure SQL Elastic Pools, a key feature for managing multiple databases with variable and unpredictable usage patterns. For the DP-900 exam, you need to understand the resource sharing model, eDTU/vCore concepts, configuration options, and when to use elastic pools versus single databases or managed instances. Approximately 5-10% of exam questions touch on elastic pools, often comparing them to other deployment options in the relational data domain.
Jump to a section
Imagine a company that rents a shared office suite with 10 desks, a conference room, and a kitchen. Each department (Sales, Engineering, Support) is like a database in an elastic pool. The office suite has a total capacity: 10 desks, but departments can use any number of desks as needed, as long as the total does not exceed 10. Sales might need 5 desks during a campaign, Engineering 4 desks for a project, and Support 1 desk. If all departments need 7 desks at once, they can use 7; the remaining 3 are idle. The company pays for the entire suite (the pool), not per desk per department. If one department needs more than 10 desks, the company must rent a bigger suite (scale up the pool). If the company had private offices for each department, they would each have a fixed number of desks (e.g., Sales 3, Engineering 4, Support 2), and if Sales needed 5, they would be stuck unless they moved to a bigger private office. The shared suite is elastic: departments share capacity, and the total cost is lower because unused desks in one department can be used by another. This is exactly how Azure SQL Elastic Pools work: multiple databases share a fixed pool of resources (DTUs or vCores), and each database can burst up to a per-database max, while the pool has a total limit. You pay for the pool, not per database, saving costs when databases have variable usage patterns.
What is an Azure SQL Elastic Pool?
An Azure SQL Elastic Pool is a deployment option for Azure SQL Database that allows multiple databases to share a common set of resources (CPU, memory, data I/O, transaction log I/O) within a single logical server. The pool has a defined total resource limit (expressed in eDTUs or vCores) and each database in the pool can automatically scale its resource consumption up to a configurable per-database maximum (max DTU/vCore). This model is designed for SaaS applications or multi-tenant databases where individual databases have low average usage but occasional spikes, enabling cost savings by pooling resources instead of provisioning each database with its own dedicated resources.
Why Elastic Pools Exist
Before elastic pools, each Azure SQL Database had to be provisioned with a fixed service tier (Basic, Standard, Premium) and performance level (e.g., S2, S3). For a SaaS provider with hundreds of customer databases, each database might need only S0 (10 DTUs) on average but occasionally spike to S2 (50 DTUs). Provisioning every database at S2 would be wasteful and expensive. Elastic pools solve this by allowing many databases to share a pool of, say, 1000 eDTUs. Each database can burst up to 50 DTUs, but the total consumption across all databases never exceeds 1000 eDTUs. This reduces cost because you pay for the pool's total resources, not the sum of individual database peaks.
How Elastic Pools Work Internally
An elastic pool is hosted on a single Azure SQL Database server (logical server) and consists of a set of databases that all reside on the same underlying hardware node (or a set of nodes for larger pools). The pool has a resource governor that enforces the total resource limits. Each database in the pool has a guaranteed minimum resource allocation (min DTU/vCore) and a maximum per-database limit (max DTU/vCore). The resource governor uses a token bucket algorithm to allocate resources. When a database needs more resources, it requests tokens from the pool. If the pool has available capacity (total usage < pool limit), the database can burst up to its max. If the pool is fully utilized, databases are throttled back to their minimum or share remaining capacity fairly.
Key Components, Values, Defaults, and Timers
eDTU (elastic Database Transaction Unit): A blended measure of CPU, memory, and I/O. Pool sizes are specified in eDTUs (e.g., 100, 200, 400, 800, 1200, 1600, 2000, 2500, 3000 eDTUs). Standard tier pools range from 100 to 3000 eDTUs; Premium pools from 125 to 4000 eDTUs (with additional storage and IO).
vCore: For vCore-based purchasing model, pools are specified in vCores (e.g., 4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 80, 128 vCores). vCore pools are available in General Purpose, Business Critical, and Hyperscale service tiers.
Per-database settings: Each database in a pool has a min DTU/vCore and max DTU/vCore. Min DTU ensures a baseline performance; max DTU limits a single database's resource consumption. For example, in a 1000 eDTU Standard pool, you might set min=10 and max=100 for each database. Default min is 0, default max equals the pool's per-database max limit (which depends on pool size).
Pool size limits: The number of databases per pool is limited. For Standard tier, max databases per pool is 100 (for 100 eDTU) to 500 (for 3000 eDTU). For Premium, max is 100 for 125 eDTU to 500 for 4000 eDTU. vCore pools have similar limits.
Storage per database: Each database in a pool has its own storage limit (data size). In Standard tier, max storage per database ranges from 250 GB (for small pools) to 500 GB (for large pools). Premium pools allow up to 1 TB per database. vCore General Purpose allows up to 4 TB per database; Business Critical up to 4 TB; Hyperscale up to 100 TB.
Resource governance: Azure uses a scheduler that monitors pool usage every few seconds. If a database exceeds its max DTU, it is throttled. If the pool total exceeds its eDTU limit, all databases are throttled proportionally based on their min and max settings.
Timers: Throttling is applied within seconds of exceeding limits. There is no configurable timer; it's immediate.
Configuration and Verification Commands
You can create an elastic pool using Azure Portal, PowerShell, Azure CLI, or REST API. Using Azure CLI:
# Create a resource group
az group create --name myResourceGroup --location eastus
# Create a logical server
az sql server create --name myServer --resource-group myResourceGroup --admin-user adminuser --admin-password Password123!
# Create an elastic pool (Standard tier, 200 eDTU)
az sql elastic-pool create --name myPool --resource-group myResourceGroup --server myServer --edition Standard --dtu 200 --db-dtu-min 10 --db-dtu-max 100
# Add a database to the pool
az sql db create --resource-group myResourceGroup --server myServer --name myDatabase --elastic-pool myPool
# View pool metrics
az sql elastic-pool list-metrics --name myPool --resource-group myResourceGroup --server myServerTo verify pool usage in Azure Portal, navigate to the pool's Monitoring blade. Key metrics: eDTU percentage, CPU percentage, Data IO percentage, Log IO percentage, Sessions count, Storage percentage.
Interaction with Related Technologies
Elastic Pool vs. Single Database: Single databases are isolated with dedicated resources. Pools share resources. Choose pools when databases have low average utilization but occasional peaks; choose single databases when workloads are steady or require predictable performance.
Elastic Pool vs. Managed Instance: Managed Instance is a fully managed SQL Server instance with instance-scoped features (linked servers, SQL Agent, cross-database queries). Elastic pools are for individual databases on a logical server. Managed Instance has its own resource limits per instance (up to 80 vCores, 16 TB storage). You cannot use elastic pools with Managed Instance directly; instead, you can use instance pools (preview) for scaling.
Elastic Pool and Hyperscale: Hyperscale is a service tier for single databases, not for pools. However, you can have a Hyperscale database in a pool? No, Hyperscale databases cannot be added to elastic pools. Pools are only for General Purpose and Business Critical tiers in vCore model, and Standard/Premium in DTU model.
Elastic Database Jobs: To manage many databases in a pool, use Elastic Database Jobs (via Elastic Job agent) to run T-SQL scripts across all databases.
Elastic Query: Allows querying across multiple databases in a pool using external tables.
Exam-Relevant Details
The exam asks: "Which deployment option allows multiple databases to share resources?" Answer: Elastic pool.
Know the two purchasing models: DTU and vCore. DTU pools use eDTU; vCore pools use vCores.
Understand that per-database min DTU guarantees a baseline; per-database max prevents a single database from starving others.
Be aware that you can move databases in and out of a pool without downtime (via Azure Portal or PowerShell).
Pricing: You pay for the pool's total resources, not per database. However, each database still has its own storage billing (data size).
Common wrong answer: "Elastic pools provide unlimited storage per database." Reality: Each database has a max storage limit based on pool tier and size.
Another trap: "Elastic pools are available for Managed Instance." False. They are only for Azure SQL Database (logical server).
Assess workload pattern
Before creating an elastic pool, analyze the usage patterns of your databases. Look at average DTU consumption, peak DTU consumption, and the number of databases. If most databases have low average usage (below 10 DTU) but occasional spikes to 50 DTU, and you have 100+ databases, a pool is cost-effective. If databases have steady high usage, single databases may be better. Use Azure Metrics or Query Performance Insight to gather historical data. This step is crucial because a misjudged workload can lead to over-provisioning (wasting money) or under-provisioning (causing throttling).
Choose purchasing model and tier
Decide between DTU-based (Standard, Premium) or vCore-based (General Purpose, Business Critical) purchasing model. DTU is simpler for basic needs; vCore offers more flexibility (reserved instances, hybrid benefits). For the exam, know that Standard tier is for general-purpose workloads with moderate performance; Premium is for high I/O and low latency. vCore General Purpose is for most workloads; Business Critical provides high availability with multiple replicas. Also consider Hyperscale (single database only). The choice affects pool limits, storage, and cost.
Determine pool size and per-database limits
Calculate the total eDTU/vCore needed: sum of average DTU of all databases, plus buffer for peaks. For example, 200 databases each averaging 5 DTU = 1000 DTU. Then set pool eDTU to 1000 or 1200. Set per-database max to the highest peak you expect (e.g., 50 DTU). Set per-database min to ensure a baseline (e.g., 5 DTU). Default min is 0, which means a database could get no resources if pool is full. Setting min too high reduces the number of databases you can fit. The pool size limits the total number of databases (e.g., 100 eDTU pool max 100 databases). Use the formula: (pool eDTU - (num_databases * min_dtu)) / (max_dtu - min_dtu) to estimate if the pool can handle peaks.
Create the elastic pool
Use Azure Portal, CLI, or PowerShell to create the pool. Specify resource group, server name, pool name, edition (Standard, Premium, GeneralPurpose, BusinessCritical), pool size (eDTU or vCores), per-database min and max. Example CLI command: az sql elastic-pool create --name mypool --resource-group myrg --server myserver --edition Standard --dtu 200 --db-dtu-min 10 --db-dtu-max 100. The pool will be provisioned within minutes. During creation, you can also add existing databases from the same server to the pool. Databases can be moved later without downtime.
Add databases and monitor
After pool creation, add databases using Azure Portal or CLI: az sql db create --resource-group myrg --server myserver --name mydb --elastic-pool mypool. You can also move existing databases: az sql db update --resource-group myrg --server myserver --name mydb --elastic-pool mypool. Monitor pool metrics: eDTU percentage, storage percentage, and per-database metrics. If eDTU percentage consistently exceeds 80%, consider scaling up the pool. If it's below 20%, consider scaling down. Use Azure Monitor alerts to get notified. Also monitor throttling events (Resource Governor warnings) to see if per-database max is too low.
A typical enterprise scenario is a SaaS company providing a multi-tenant application. Each tenant has its own Azure SQL Database (to ensure isolation). The company has 500 tenants, each with low activity most of the time (average 2 DTU) but occasional spikes during month-end reporting (up to 100 DTU). If they provision each database at S2 (50 DTU), the cost would be 500 * $0.15/hr = $75/hr. Instead, they create a Standard elastic pool with 1000 eDTU, per-database max 100 DTU, min 0 DTU. The pool cost is about $0.50/hr, a huge savings. They add all 500 databases to the pool. During normal operation, total consumption is 500*2 = 1000 eDTU, exactly the pool limit. During month-end, some databases spike, but not all at once; the pool handles it. If too many spike simultaneously, they might see throttling. To mitigate, they set per-database max to 100 but also increase pool size to 1200 eDTU. They also use Elastic Database Jobs to run maintenance scripts across all databases.
Another scenario: A retail company with regional databases for each store. Each store database has variable load based on time of day. They use a Business Critical vCore pool with 16 vCores to ensure low latency for transactions. They set per-database min to 0.5 vCore to guarantee responsiveness, and max to 4 vCores. The pool is in a paired region for disaster recovery. They monitor pool storage and scale up when needed. A common mistake is not setting per-database max high enough: one store's database during a sale event might hit the max and get throttled, causing user complaints. They learned to adjust max based on historical peaks.
A third scenario: A financial services company uses elastic pools for dev/test environments. They have dozens of databases for different development branches. Usage is sporadic. They create a small pool (100 eDTU) and add all databases with min=0. Developers can spin up databases without worrying about individual DTU limits. Cost is low because the pool is small. However, they must ensure that no single database consumes all resources; they set max DTU to 20 per database. They also use auto-scaling scripts to increase pool size during business hours and decrease at night. Misconfiguration here could lead to one developer's query slowing down everyone else, so they set min DTU to 5 for critical databases.
The DP-900 exam tests elastic pools under objective 2.2 (Relational Data) specifically comparing deployment options. Key exam points: - Elastic Pool Definition: A pool of shared resources (eDTU/vCore) for multiple databases. Not for single databases or Managed Instances. - When to use: Databases with variable and unpredictable usage, low average utilization, occasional spikes. Not for steady high-usage workloads. - Resource sharing: Per-database min and max settings. Min guarantees baseline; max limits burst. Pool total limit is the sum of eDTU/vCore. - Pricing: Pay for pool resources, not per database. Storage billed separately per database. - Limits: Max databases per pool depends on pool size (e.g., 100-500). Max storage per database limited (e.g., 500 GB for Standard, 1 TB for Premium, 4 TB for General Purpose). - Common wrong answers: 1. "Elastic pools provide unlimited storage." Wrong: storage per database is capped. 2. "Elastic pools can be used with Managed Instance." Wrong: Managed Instance has its own resource model (instance pools). 3. "In an elastic pool, each database gets a fixed amount of resources." Wrong: resources are shared; databases can burst up to max. 4. "Elastic pools are always cheaper than single databases." Wrong: if databases have steady high usage, single databases may be cheaper. - Numbers to memorize: Standard pool eDTU sizes: 100, 200, 400, 800, 1200, 1600, 2000, 2500, 3000. Premium: 125, 250, 500, 1000, 1500, 2000, 2500, 3000, 4000. vCore: 4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 80, 128. Max databases per pool: 100 for smallest, 500 for largest. - Edge cases: Hyperscale databases cannot be in a pool. Elastic pools are only for Azure SQL Database (logical server). You can move databases in/out of pool with no downtime. The pool's service tier must match the database's tier? Actually, you can only add databases of the same service tier (Standard, Premium, General Purpose, Business Critical) to a pool of that tier. - How to eliminate wrong answers: Ask: "Does this option share resources across multiple databases?" If yes, it's likely an elastic pool. If the question mentions "guaranteed resources" or "isolated performance", it's a single database. If it mentions "instance-level features" like SQL Agent, it's Managed Instance. - Exam tip: Read the scenario carefully. If it says "multiple databases with low average usage but occasional spikes," choose elastic pool. If it says "each database needs consistent performance," choose single database.
An elastic pool allows multiple Azure SQL Databases to share a fixed set of resources (eDTU or vCores).
Each database in a pool has a configurable min and max resource limit to guarantee baseline and prevent starvation.
Elastic pools are cost-effective for SaaS applications with many databases that have low average utilization but occasional spikes.
Standard pools range from 100 to 3000 eDTU; Premium from 125 to 4000 eDTU; vCore pools from 4 to 128 vCores.
Maximum databases per pool ranges from 100 (smallest pool) to 500 (largest pool).
Storage per database is limited: Standard up to 500 GB, Premium up to 1 TB, General Purpose up to 4 TB, Business Critical up to 4 TB.
Hyperscale databases cannot be added to elastic pools.
Moving databases in/out of a pool causes no downtime.
Elastic pools are not available for Managed Instance.
Monitor pool eDTU percentage; scale up if consistently above 80%, scale down if below 20%.
These come up on the exam all the time. Here's how to tell them apart.
Azure SQL Elastic Pool
Multiple databases share a pool of resources (eDTU/vCore).
Cost-effective for databases with variable and low average usage.
Per-database min and max settings allow bursting.
Maximum number of databases per pool is limited (100-500).
Storage is per database, not shared.
Single Azure SQL Database
Each database has its own dedicated resources (DTU/vCore).
Predictable performance; no resource contention.
No per-database min/max; you choose a fixed service tier.
No limit on number of databases per server (but server has limits).
Storage is per database, but you can choose up to 4 TB (Hyperscale up to 100 TB).
Mistake
Elastic pools provide unlimited storage per database.
Correct
Each database in a pool has a maximum storage limit determined by the pool's service tier and size. For Standard pools, max storage per database ranges from 250 GB to 500 GB; for Premium, up to 1 TB; for vCore General Purpose, up to 4 TB. Storage is billed per database, not shared.
Mistake
All databases in an elastic pool share the same performance level.
Correct
Each database can have different per-database min and max DTU/vCore settings. This allows fine-grained control. For example, a critical database can have min=50, while a test database has min=0.
Mistake
Elastic pools are available for Azure SQL Managed Instance.
Correct
Elastic pools are only for Azure SQL Database (single databases on a logical server). Managed Instance has its own scaling options, including instance pools (preview) which are conceptually similar but not the same.
Mistake
Moving a database into an elastic pool causes downtime.
Correct
Databases can be moved in and out of elastic pools with no downtime. The operation is online and typically completes within minutes. The database remains accessible during the move.
Mistake
Elastic pools always reduce costs compared to single databases.
Correct
Cost savings occur only when databases have low average utilization and can share resources. If databases have steady high usage, single databases may be more cost-effective because you pay only for what you need without over-provisioning a pool.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
DTU (Database Transaction Unit) is a blended measure of CPU, memory, and I/O for a single database. eDTU (elastic DTU) is the same measure but for an elastic pool. When you create a pool, you specify eDTU for the pool, and each database in the pool can consume up to its per-database max DTU. The pool's total eDTU is the sum of all databases' usage. So eDTU is just DTU applied to pool context.
Yes, you can move an existing single database into an elastic pool using Azure Portal, PowerShell, or CLI. The database must be on the same logical server and in the same service tier (Standard, Premium, General Purpose, Business Critical) as the pool. The move is online with no downtime. Example CLI: az sql db update --resource-group myrg --server myserver --name mydb --elastic-pool mypool.
When the total eDTU consumption of all databases in the pool reaches the pool's eDTU limit, resource governance throttles databases. Databases that are exceeding their per-database max DTU are throttled first. If that doesn't reduce usage, databases are throttled proportionally based on their per-database min settings. This can cause slower query performance. To avoid this, you should monitor pool eDTU percentage and scale up the pool if needed.
No. All databases in an elastic pool must be in the same service tier. For example, you cannot mix Standard and Premium databases in the same pool. Similarly, for vCore model, you cannot mix General Purpose and Business Critical databases in one pool. However, you can have multiple pools on the same server, each with different tiers.
Each database in an elastic pool has its own storage allocation, and you are billed for the total storage used across all databases in the pool. Storage billing is separate from pool resource billing. For example, if you have 100 databases each using 1 GB, you pay for 100 GB of storage. The pool's resource cost (eDTU/vCore) is a separate line item.
Per-database min DTU/vCore guarantees a minimum level of resources for a database, ensuring it always gets at least that amount. Per-database max limits how much a single database can consume, preventing it from starving other databases. For example, setting min=10 and max=100 means the database will always have at least 10 DTU, but can burst up to 100 if the pool has capacity.
No. Hyperscale is a service tier designed for single databases that require very high scalability (up to 100 TB). Hyperscale databases cannot be added to elastic pools. If you need Hyperscale, you must use a single database. For multi-database scenarios with Hyperscale, consider sharding.
You've just covered Azure SQL Elastic Pools — now see how well it sticks with free DP-900 practice questions. Full explanations included, no account needed.
Done with this chapter?