If you have a database that isn’t used constantly — an internal app, a dev/test environment, or a system with spikes and idle hours — paying for a server running 24/7 is wasting money. Azure SQL Database serverless solves that: it scales compute automatically and pauses when no one is using it, billing you per second. In this guide you’ll see what it is, its pros and cons, how to set it up, and roughly what it costs.

What is Azure SQL serverless?

It’s a compute tier of Azure SQL Database (within the vCore model, General Purpose tier) that adjusts resources on its own: you define a minimum and maximum number of vCores and the database scales between them based on demand. If there’s no activity for the period you configure, it auto-pauses and you stop paying for compute (you only pay for storage). On the next connection, it resumes on its own.

Benefits

  • You pay for real usage: compute is billed per second, based on the vCores actually used.
  • Auto-pause: during idle periods you pay no compute — ideal for intermittent workloads (dev/test, internal apps, seasonal).
  • Auto-scale: it scales up and down between your minimum and maximum without manual intervention during spikes.
  • Less administration: you don’t have to size or re-scale by hand.

Drawbacks

  • Cold-start latency: after an auto-pause, the first connection takes time to resume (seconds, sometimes up to ~1 minute). Bad for apps that always require an immediate response.
  • Not ideal for constant load: if the database works almost all day, the provisioned tier is cheaper and more predictable.
  • Variable cost: during spikes it scales up (and bills more); spend is less predictable than a fixed price.
  • Pause limitations: auto-pause is a General Purpose tier feature, and certain connections or features prevent it (if something keeps the database active, it never pauses).
  • Cold cache: after a pause, the first queries are slower until memory fills again.

Step by step (Azure Portal)

  1. Portal → Create a resource → Azure SQL → SQL Database → Create.
  2. Choose subscription and resource group, and a name for the database.
  3. Under Server, create a new one (name, admin login and password, region).
  4. Under Compute + storage → Configure: General Purpose tier, Serverless compute tier. Set max vCores, min vCores, the auto-pause delay (minimum 1 hour) and the storage size.
  5. Under Networking, allow access (add your IP as a firewall rule or enable Azure services).
  6. Review and create. Connect with SSMS or Azure Data Studio using the connection string.

With Azure CLI

# Logical server (once)
az sql server create -n MYSERVER -g MYGROUP -l eastus2 
  -u adminuser -p 'YourStrongPassword!'

# Serverless database: General Purpose, Gen5, max 2 vCores, min 0.5, auto-pause at 60 min
az sql db create -g MYGROUP -s MYSERVER -n MYDB 
  --edition GeneralPurpose --family Gen5 --compute-model Serverless 
  --capacity 2 --min-capacity 0.5 --auto-pause-delay 60

# Firewall rule for your IP
az sql server firewall-rule create -g MYGROUP -s MYSERVER 
  -n my-ip --start-ip-address 200.0.0.1 --end-ip-address 200.0.0.1

--auto-pause-delay is in minutes (minimum 60); use -1 to disable auto-pause.

Approximate cost

Serverless is billed by vCore-second of compute plus storage. As a reference (General Purpose tier, Gen5, an East US 2-type region; prices vary by region — confirm in the Azure pricing calculator):

  • Compute: ~US$0.52 per vCore-hour while active.
  • Storage: ~US$0.115 per GB per month.
  • Paused: US$0 compute (storage only).

Example — an intermittently used database (~0.75 vCores average, ~8 h/day, 22 business days, paused the rest), 32 GB:

  • Compute: 0.75 × 0.52 × 8 × 22 ≈ ~US$69/month
  • Storage: 32 × 0.115 ≈ ~US$4/month
  • Total ≈ US$73/month

Compare that with a provisioned 2-vCore database running 24/7: 2 × 0.52 × 730 ≈ ~US$759/month. For intermittent workloads the savings are huge; for constant load, provisioned wins.

When to use it

Yes: dev/test, internal apps with idle hours, seasonal or unpredictable workloads, new projects with no clear usage pattern. Better to avoid: production with constant, high traffic, or where cold-start latency is unacceptable.

Conclusion

Azure SQL serverless shines when your database doesn’t work all the time: you pay for what you use and it shuts itself down. The key is knowing your usage pattern — if it’s intermittent, you save a lot; if it’s constant, provisioned is better.

Keep reading: Azure Storage as SFTP · Design & Architecture.

At Grupo TANDEM we design and implement Azure infrastructure optimized for cost and performance. If you want to choose well between serverless and provisioned for your case, let’s talk.