SQL Managed Instance Database
Does ZopNight manage SQL Managed Instance Database?
SQL Managed Instance databases carry no separate meter. Compute and storage bill at the parent instance, which reserves vCores 24/7. ZopNight discovers each database via Resource Graph and attaches it under its managed instance in the topology, so instance-level spend can be read against what actually runs on it.
Rules that fire on SQL Managed Instance Database
No active rule family targets SQL Managed Instance Database today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery only; billing occurs at the managed-instance level. |
A database hosted on an Azure SQL Managed Instance. Individual databases share the instance’s provisioned compute and storage.
The instance pays; the database consumes
Databases on a managed instance have no meter of their own. The parent instance reserves vCores, memory, and storage as a single block and bills for all of it continuously; each database simply draws from that shared allocation. No per-database charge appears on the invoice, which is convenient for accounting and terrible for accountability, since nothing on the bill says which database earns its keep and which is dead weight holding the reservation at its current size.
Why ZopNight inventories databases it cannot bill
ZopNight discovers each database via Azure Resource Graph and attaches it under its parent managed instance in the topology, so instance-level spend can be understood in context. The value is entirely in that context: an instance line item becomes explainable when the databases behind it are enumerable, owned, and dated. Since billing occurs at the managed-instance level, this type is discovery only: there is nothing to schedule, pause, or rightsize on the database itself; every action lands on the parent.
Dead databases keep expensive instances big
The waste pattern specific to this type is indirect but potent. Managed instances are sized for the sum of what they host, and databases accumulate: test restores that outlived their test, copies made before a risky migration, applications retired without their data. Each dead database looks free (it has no meter) while collectively they justify a vCore reservation the live workload alone would not need. Clearing them is the prerequisite for shrinking the instance, which is where the actual saving lives.
Reaching these databases in the portal
Azure portal → Azure SQL → SQL managed instances, then open the instance: its databases are listed on the instance blade with their creation dates and sizes. Sorting by creation date is the quickest way to spot restores and copies that nobody ever deleted.