Skip to content
Ask the community about this page

Create an Azure SQL Database Scaling package

Timextender Orchestration & Data Quality 23.3+Timextender Data Platform 26.3+cloud

An Azure SQL Database Scaling package rescales a database to a different service tier when it runs. Scale up for the load window, back down for the day.

Before you start

  • An Azure App Registration data provider in the workspace

The Azure App Registration whose service principal this package acts as. It decides which Azure resources you can choose below.

  • The principal able to enumerate resource groups in the subscription. This package finds its resource that way, so without it the resource list is empty and the package cannot be completed.
  • The principal needs permission to change the resource, not only read it. Listing it and scaling it are different rights.

How it works

You choose a data provider, then an Azure SQL database to act on, then what to do to it.

When the resource list is empty the editor says so explicitly, naming the scope it searched — No … were found in … this data provider can see. That is a permissions answer, not a fault.

Each of these packages performs one action. Scaling up before a load and back down afterwards is two packages, ordered in a process map or on a schedule — which is also what makes the saving visible in the execution log.

Purchasing model, tier and capacity

Three fields, in order, because each narrows the next:

vCore or DTU. It decides which service tiers and capacities the database can be scaled to.

The tier the database is scaled to when the package runs.

The purchasing model must match how the database is licensed — choosing the other model does not convert it, it simply offers tiers that do not apply. Then the service tier (Basic, Standard, Premium for DTU) and the capacity within it.

Scaling is not instantaneous and is not free of disruption: connections can drop as the database moves. Schedule it outside query hours, not in the middle of a report run.

Steps

Screenshots stop at the data provider

The images are real but end there: no service principal on our test environment can enumerate resource groups, so the resource and action steps have no screenshot yet. The prose comes from the product's own field help and validation.

1. Create the package

Orchestration → Packages → Create, then Azure SQL Database Scaling from the Azure area.

Azure SQL Database Scaling in the picker

A new Azure SQL Database Scaling package

2. Choose the data provider

The data provider list

3. Choose the resource, then the action

Both come from the selections above. Here the action is three fields, in order: Purchasing model, then Service tier, then Capacity. If the resource list is empty, see Troubleshooting.

4. Save

Saves as a Draft.

A worked pattern

Scale to a higher tier before the nightly load, and back to the day-time tier when it finishes.

Best practices

Pair the packages. A scale-up with no matching scale-down is how a cost-optimisation exercise becomes a cost increase. Put both in the same process map.

Order them around the work, not on a clock. A scale-down scheduled for 06:00 will run whether or not the load finished. A scale-down that depends on the load step will not.

Make the down action the one that cannot be skipped. If the flow can fail between up and down, arrange for the down step to run anyway.

Give the principal least privilege, scoped to the specific resource rather than the subscription.

Check the cost model before assuming a saving. Not every action stops billing — the field help is explicit about which ones do.

Troubleshooting

The resource list is empty. The service principal cannot enumerate resource groups, or cannot see resources of this type. Grant subscription-level Reader or Microsoft.Resources/subscriptions/resourceGroups/read, then use the refresh button. The editor's own message names the scope it searched.

The resource lists but the action fails at run time. Read permission without write permission. The principal needs a role that can change the resource, not just see it.

The package succeeds but nothing changed. The resource was already in the target state. These actions are idempotent, which is usually what you want, but it means "succeeded" does not prove anything moved.

A resource that was renamed or deleted in Azure. The package stores the reference it was configured with. Reopen it, re-pick from the refreshed list, and save.

Reference

Fields

Field Required Notes
Data provider Yes Azure App Registration; decides which resources are selectable
Resource Yes Found via the subscription and resource group; has a refresh button
Purchasing model Yes vCore or DTU
Service tier Yes Narrowed by the model
Capacity Yes Narrowed by the tier
Advanced JSON No For settings the form does not expose

Validation: Please select a data provider, Please select a database, Please select a purchasing model, Please select a service tier, Please select a compute capacity.

Discussed in the community

Looking for related questions…

Didn't find your answer? Ask the community about this page — questions are answered by Timextender experts, partners and other users.