One of the advantages of Azure SQL Database is the ability to scale compute resources without managing the underlying infrastructure.
Changing from 4 vCores to 8 vCores can be only a few clicks or a single command.
But there is a question I frequently see when troubleshooting scaling operations:
“Why is my Azure SQL Database scaling operation taking so long?”
An even more interesting question appears when two databases undergo what looks like the same change:
Database A
Business Critical → Business Critical
Scaling duration: ~1 hour 15 minutes
Database B
Business Critical → Business Critical
Scaling duration: ~2 hours 15 minutes
Same service tier.
Similar scaling request.
Very different completion time.
At first glance, that might look unusual.
However, a scale operation isn’t simply Azure changing a configuration value from one number of vCores to another.
Depending on the source and target configuration, Azure SQL Database can need to provision target compute, prepare or copy database data, transition connections to the target compute, and clean up the original environment. Microsoft specifically notes that creating a database replica on the new compute instance for some scaling combinations can strongly influence the overall latency.
Let’s look at what happens and, more importantly, how to monitor it.
Scaling Is More Than Changing vCores
When you submit a scaling request such as:
Business Critical
4 vCores
↓
Business Critical
8 vCores
it’s tempting to imagine something like:
CPU allocation: 4 → 8
Done.
That isn’t necessarily what happens.
At a high level, Microsoft documents a scaling workflow involving two important stages:
- Create a new compute instance with the requested service tier and compute size
- Switch routing from the original compute instance to the new one
For some combinations of service-tier and compute-size changes, Azure SQL Database must also create a replica on the new compute instance, involving data copying.
A simplified view is:
Scaling request
↓
Prepare target compute
↓
Prepare/copy database if required
↓
Bring target environment ready
↓
Switch connections
↓
Scaling complete
The important takeaway is:
A scale operation can involve moving database execution to a new compute environment, not simply increasing CPU on the existing environment.
Why Can Two Similar Databases Take Different Amounts of Time?
This is where troubleshooting becomes interesting.
Imagine two databases:
Database A
4 vCores → 8 vCores
Completed in 75 minutes
Database B
4 vCores → 8 vCores
Completed in 135 minutes
The natural question is:
“If the source and destination configurations are the same, shouldn’t the duration also be the same?”
Not necessarily.
The requested configuration tells us where the database needs to end up. It does not mean the work required to reach that state is identical.
Several factors can affect the operation.
1. Database Size and Data Movement
One of the most important factors can be the amount of data that must be prepared on the target compute.
Microsoft’s scaling documentation explicitly states that for some source/target combinations, a replica must be created on the new compute instance. That involves copying data and can significantly affect the overall scaling latency.
Conceptually:
Small database
Provision
████
Data preparation
██████
Switch
█
versus:
Large database
Provision
████
Data preparation
████████████████████████
Switch
█
Database size alone doesn’t provide a precise prediction of completion time, but it can influence the amount of work required during applicable scaling paths.
2. Workload Activity Matters
A database also doesn’t necessarily stop processing application traffic while Azure prepares the target environment.
Microsoft states that during target compute creation, the database remains online and connections continue to the original compute instance.
That creates an interesting challenge:
Target environment preparing
+
Application still generating workload
A highly active transactional database and a relatively idle database can therefore present different operational conditions during scaling.
The practical lesson is:
Two databases with the same service objective aren’t necessarily in the same workload state when scaling begins.
When investigating a slow scale operation, look at the activity around the scaling window, including:
- transaction volume;
- write activity;
- long-running transactions;
- workload peaks;
- batch operations;
- maintenance activity.
3. Long-Running Transactions Can Affect Switchover
Toward the end of scaling, connections need to transition to the target compute instance.
Microsoft documents that existing connections to the original compute are dropped and new connections are established to the target compute. The switch generally results in a short interruption, often only a few seconds and generally less than 30 seconds.
However, there’s an important exception.
Microsoft notes that:
If long-running transactions are active when connections are dropped, the switch can take longer because aborted transactions need to recover.
Conceptually:
Normal transition
Target ready
↓
Switch
↓
Reconnect
↓
Done
With a long-running transaction:
Target ready
↓
Connection transition
↓
Transaction interruption
↓
Recovery work
↓
Reconnect
↓
Done
This is one reason application workload should be considered when evaluating scaling duration.
4. Resource Availability Can Matter
Another clue comes from Azure SQL’s operation-status metadata.
The sys.dm_operation_status DMV exposes several states for database operations, including:
PENDING
IN_PROGRESS
COMPLETED
FAILED
CANCEL_IN_PROGRESS
CANCELLED
Importantly, Microsoft defines PENDING as an operation waiting for resource or quota availability.
That means some of the elapsed time around an operation may occur before active processing progresses as expected.
This is why comparing scale operations purely by database size or vCore count can be misleading.
How Can I Monitor a Scaling Operation?
Rather than repeatedly refreshing the Azure portal, there are several useful methods for inspecting progress.
Method 1: Azure PowerShell with Get-AzSqlDatabaseActivity
Azure PowerShell provides:
Get-AzSqlDatabaseActivity
Microsoft documents this cmdlet specifically for retrieving the status of operations against Azure SQL databases.
For example:
Get-AzSqlDatabaseActivity `
-ResourceGroupName “MyResourceGroup” `
-ServerName “myserver” `
-DatabaseName “mydatabase”
This can help identify database operations associated with the selected database.
For clearer output:
Get-AzSqlDatabaseActivity `
-ResourceGroupName “MyResourceGroup” `
-ServerName “myserver” `
-DatabaseName “mydatabase” |
Select-Object `
Operation,
OperationId,
DatabaseName,
State,
PercentComplete,
StartTime,
ErrorCode,
ErrorMessage
The specific fields returned can vary with module/API behavior, so always interpret them in the context of the operation being monitored.
The important point is that you’re no longer asking only:
“Is scaling still happening?”
You can inspect the operation itself.
Method 2: Check Current and Requested Service Objectives
Another useful PowerShell command is:
Get-AzSqlDatabase
Microsoft documents this cmdlet for retrieving Azure SQL Database properties. Its output includes service-objective information such as CurrentServiceObjectiveName and RequestedServiceObjectiveName.
For example:
Get-AzSqlDatabase `
-ResourceGroupName “MyResourceGroup” `
-ServerName “myserver” `
-DatabaseName “mydatabase” |
Select-Object `
DatabaseName,
Status,
Edition,
CurrentServiceObjectiveName,
RequestedServiceObjectiveName
During a change, comparing these fields can help establish the current and requested configuration.
Think of it as:
CurrentServiceObjectiveName
↓
Where am I now?
RequestedServiceObjectiveName
↓
Where am I trying to go?
Once the operation completes successfully, the current configuration should reflect the requested target.
Method 3: Use sys.dm_operation_status
For SQL-side monitoring, sys.dm_operation_status provides information about database operations such as CREATE and ALTER.
For example:
SELECT
major_resource_id,
operation,
state_desc,
percent_complete,
start_time,
last_modify_time,
error_code,
error_desc
FROM sys.dm_operation_status
ORDER BY start_time DESC;
Useful columns include:
- operation
- state_desc
- percent_complete
- start_time
- last_modify_time
- error_code
- error_desc
Microsoft defines the operation states as including PENDING, IN_PROGRESS, COMPLETED, and FAILED.
Be Careful With PercentComplete
This is an important detail.
It is tempting to interpret:
PercentComplete = 50
as:
“Half of the work is finished, so half of the remaining time is left.”
That isn’t necessarily correct.
For sys.dm_operation_status, Microsoft documents percent_complete for most operations as:
0 = Operation not started
50 = Operation in progress
100 = Operation complete
Restore operations are an important exception, where values between 1 and 99 can indicate more granular progress.
So for a normal ALTER/scale operation:
50%
should generally be interpreted as:
The operation is in progress
rather than:
Exactly half the work remains.
This distinction is very useful when communicating with application teams during long-running operations.
A Practical Monitoring Script
For PowerShell users, I like combining the configuration and operation views.
First check the database:
$db = Get-AzSqlDatabase `
-ResourceGroupName “MyResourceGroup” `
-ServerName “myserver” `
-DatabaseName “mydatabase”
$db | Select-Object `
DatabaseName,
Status,
Edition,
CurrentServiceObjectiveName,
RequestedServiceObjectiveName
Then check database operations:
Get-AzSqlDatabaseActivity `
-ResourceGroupName “MyResourceGroup” `
-ServerName “myserver” `
-DatabaseName “mydatabase”
This gives you two complementary perspectives:
DATABASE STATE
+
OPERATION STATE
↓
Better understanding
of scaling progress
What About Application Availability During Scaling?
One of the biggest concerns is:
“Does the database remain available while scaling?”
For Azure SQL Database, Microsoft states that the database remains online while the new compute environment is being prepared. Connections continue to the original compute during that stage.
The important availability event occurs during the transition.
At switchover:
Existing connections
↓
Dropped
↓
Routing switches
↓
New connections
↓
Target compute
Microsoft says the switch generally causes an interruption of less than 30 seconds and often only a few seconds.
Applications should therefore implement appropriate transient-error handling and retry logic. Microsoft explicitly recommends retry logic for applications and components using the database while the service tier is being changed.
Don’t Immediately Cancel a “Slow” Scaling Operation
A scale operation taking longer than expected does not automatically mean:
Scaling is stuck.
It could still be legitimately working through:
Resource availability
↓
Target compute preparation
↓
Data/replica preparation
↓
Synchronization / workload handling
↓
Switchover
Before assuming failure, gather evidence.
Check:
Operation state
Current service objective
Requested service objective
Start time
Last modification time
Error details
Workload activity
Long-running transactions
Then determine whether the operation is:
PendingActively progressingCompleted
or:
Failed
Troubleshooting Two Databases With Different Scaling Durations
Suppose you’re investigating:
Database A
Scale duration: 1h15
Database B
Scale duration: 2h15
Here is the approach I recommend.
1. Verify that the changes truly match
Compare:
Source service tier
Target service tier
Source vCores
Target vCores
Compute tier
Storage configuration
Do not assume both operations were identical simply because both ended at, for example, Business Critical 8 vCores.
2. Compare database characteristics
Look at:
Database size
Workload level
Write activity
Transaction volume
Long-running transactions
3. Compare operation timing
Retrieve:
Start time
State
Last modification time
Completion time
sys.dm_operation_status exposes this operation metadata for Azure SQL database operations.
4. Determine whether either operation spent time pending
Remember:
PENDING
can mean the operation is waiting for resource or quota availability.
That represents a very different explanation from:
“The database took longer to copy.”
5. Check workload around the transition
Look for:
Large transactions
Bulk writes
ETL operations
Maintenance
High transaction rates
Long-running transactions
particularly around the switchover period.
Scaling Duration Is Not an SLA Stopwatch
This leads to perhaps the most important takeaway.
If:
Database A took 75 minutes
you should not assume:
Database B must take approximately 75 minutes.
Even apparently similar scale operations can encounter different database and platform conditions.
A better operational expectation is:
Treat each scaling operation as an asynchronous platform operation whose duration depends on the work required to safely reach the requested configuration.
Monitor the operation rather than predicting its completion from a previous database.
Recommended Checklist
Before scaling a production Azure SQL Database:
Before
- Review workload activity.
- Identify long-running transactions or batch processes.
- Confirm the requested service objective.
- Ensure application retry logic is implemented.
- Record the UTC start time.
- Understand dependent application connection behavior.
During
Monitor:
Get-AzSqlDatabaseActivity
Get-AzSqlDatabase
sys.dm_operation_status
and watch:
State
CurrentServiceObjectiveName
RequestedServiceObjectiveName
StartTime
LastModifyTime
Error information
After
Confirm:
Current service objective = requested target
Database status = Online
Application connectivity = Healthy
Workload performance = Expected
Also validate that applications successfully reconnected after the transition.
Final Thoughts
When Azure SQL Database scaling takes longer than expected, it’s easy to think:
“Something must be wrong.”
And when two similar databases take very different amounts of time, it’s equally tempting to expect the durations to match.
But a scale operation can involve substantially more than changing a vCore number.
At a high level:
Request scaling
↓
Provision target compute
↓
Prepare/copy database when required
↓
Transition connections
↓
Complete
Microsoft’s documentation confirms that data copying for applicable scale paths can strongly influence latency, that the switchover can take longer in the presence of long-running transactions, and that a pending operation might be waiting for resource or quota availability.
So when someone asks:
“Why is Azure SQL scaling taking so long?”
my recommendation is not to start by guessing how many minutes it should take.
Instead ask:
“What state is the operation currently in, and what evidence do we have about its progress?”
With Get-AzSqlDatabaseActivity, Get-AzSqlDatabase, and sys.dm_operation_status, you can turn an opaque waiting period into a much more structured investigation.