# Scheduling SQL Server on Azure VM

> Deallocating a SQL Server VM on schedule stops both meters at once: the compute charge and the pay-as-you-go SQL Server license billed with it, which on Enterprise edition can exceed the VM cost several times over. SQL Agent jobs scheduled for 2am silently miss, and disks bill through the stop.

Source: https://zop.dev/integrations/azure/sqlvm/schedule
Updated: 2026-08-19

---

## The license meter is the headline

A pay-as-you-go SQL Server image bills its license by the second alongside the VM, and for
Enterprise edition the license line can be several times the compute line. Deallocation stops
both. That multiplier makes SQL VMs disproportionately rewarding to schedule. The same
off-hours window saves more per hour here than on an identical VM without SQL, and that is why
they belong at the top of any scheduling backlog ordered by return.

## Azure Hybrid Benefit changes the math

VMs licensed through Hybrid Benefit bring their own SQL license, so only compute stops
billing on deallocation. The schedule still pays, just at the ordinary VM rate. Check which
licensing model each VM uses before promising numbers; the same size VM saves wildly
different amounts under the two models.

## SQL Agent sleeps through its jobs

Backups at 2am, index maintenance at 3am, DBCC checks on Sundays: SQL Agent jobs live inside
the instance, and a deallocated instance runs none of them. Missed jobs do not queue or catch
up. Every scheduled SQL VM needs its maintenance calendar moved inside the powered-on window,
typically to just after the morning start or just before the evening stop, and the first week
should verify the jobs actually ran.

## Deallocate, and only deallocate

The saving depends on releasing the compute allocation. A guest-OS shutdown from inside
Windows leaves the VM allocated and billing both meters. The schedule issues the deallocation
through Azure, which is the only stop that reaches the invoice.

Premium disks underneath keep billing at their provisioned size either way, and on database VMs
those disks are rarely small, so count them in the overnight floor.

## Availability groups need a harder look

A VM participating in an availability group is not a casual scheduling candidate:
deallocating a replica breaks synchronization and can trigger failovers. Standalone dev and
test instances are the natural fleet; scheduling AG members is a deliberate architectural
decision, not a cost tweak.