Start with the idea of a database “instance”, because the whole product is built around it.

What an instance is

A database system such as SQL Server is more than a pile of tables. When you install it on a server you get an instance: a running copy of the engine with its own settings, its own list of sign-in accounts, its own scheduled jobs, its own temporary workspace and its own system databases. Inside that instance live many ordinary databases. Programs that were written for SQL Server often lean on the instance itself, not only on the tables. They may run a job at two in the morning, query two databases in one statement, read a file from a network share or send an email from inside a stored procedure. All of those abilities belong to the instance.

What “managed” means

Azure SQL Managed Instance is a platform as a service, or PaaS, version of that whole instance. You get a real instance with nearly all of the features of the newest SQL Server engine, hosted in Azure and run by Microsoft. Microsoft handles the hardware, the operating system, the database software updates, the automated backups, the monitoring and the replacement of failed machines. You keep control of the databases, the logins, the jobs, the performance tuning and the data design. It is the “lift and shift with fewer chores” option.

The Azure SQL family

What problems it solves

It lets companies leave aging servers without rewriting applications. It removes patching, backup scheduling and hardware replacement. It keeps familiar tools, such as SQL Server Management Studio, working. It ties into Azure security, monitoring and networking. And it provides built-in high availability that would cost a great deal of design and money to build on your own.

Every product answers a pain. The pain behind Managed Instance is a very ordinary one: old systems that work but cannot easily change.

The server in the basement

For decades, businesses installed SQL Server on their own machines. Over the years each server accumulated extras: dozens of databases, scheduled jobs, special sign-in accounts, connections to other systems, custom settings. Nobody planned the whole; it grew. The server became a small ecosystem, and the applications that used it depended on that ecosystem in ways that were hard to list.

The first cloud answer was not quite enough

When Microsoft launched its first managed database in the cloud, it offered single databases. These were wonderful for new applications, but a database-per-application model did not fit companies whose programs reached across databases, used jobs and relied on the instance. To move such systems you had to redesign them. Many organizations chose to rent virtual machines instead, which solved the hardware problem but left them with all the patching, backups and failover work.

A managed version of the instance

Microsoft’s answer was to host the instance itself as a managed service. It put a full engine in a private network, gave it near-complete compatibility, and kept the cloud benefits: automatic updates, backups, built-in availability and pay-as-you-go. The aim was that a typical SQL Server application could move over by restoring a backup, changing a connection string, and testing.

A handful of terms appear in nearly every Managed Instance discussion. Learn them and the portal and documentation start to read clearly.

Instance-level objects you will recognize

Because the instance is real, you get the familiar system databases. master holds the server’s own information such as logins. msdb holds the scheduled jobs, alerts and the backup history. tempdb is a shared scratch area that queries use for sorting and temporary tables. The model database is the template for new databases. You can create, drop and restore user databases as you would on any SQL Server.

Settings fixed at creation time

A few choices cannot be changed later, so decide carefully. The instance collation defines how text is sorted and compared by default, for example whether “a” and “A” are equal. The time zone of the instance determines how local dates are interpreted. Individual databases can use different collations, but the instance default is permanent. The network subnet of the instance can be changed only by moving the instance, which is a heavy operation. Choose these to match what your source server uses, so that behavior stays the same after the move.

Purchasing model

Managed Instance uses the vCore model only. You choose a number of virtual cores, which brings with it a fixed amount of memory per core, and you choose how much storage to reserve. You pay for the cores and for the storage you reserved, not for each database. There are no per-database DTU packages as in the single database service.

Two tiers and a few hardware families cover nearly every case. The tier decides how data is stored and how copies are kept, so it affects speed, availability and price at the same time.

General Purpose

The General Purpose tier is the standard choice. Compute runs on a node, while the data and log files live on remote, highly available Azure storage that is separate from compute. If the node fails, Azure starts a new node and attaches the same storage. The temporary database, tempdb, sits on fast local disk. Storage delay is a little higher than local disks, and in the classic design the input and output speed of a file depends on the size of that file, so many tiny files may get low throughput. A newer variant of the tier improves this and offers larger storage; check current documentation for what your region provides.

Business Critical

The Business Critical tier is built for the heaviest transaction workloads and the lowest delay. Data lives on fast local solid-state disks. Four copies of each database run on four nodes: one primary and three secondaries that continuously apply every change, using the same technology as Always On availability groups. A commit is confirmed only after enough secondaries have safely stored the change. If the primary fails, a secondary takes over very quickly. One secondary can answer read-only queries, so reports can be moved off the main workload. This tier also supports in-memory tables for extremely high transaction rates.

Hardware generations

Each tier can run on different hardware families, which differ in processor generation and in memory per core. The standard family offers a balanced amount of memory per core, roughly five gigabytes. A premium family uses newer processors and more memory per core, roughly seven gigabytes. A memory-optimized family offers a much higher memory ratio, in the range of thirteen gigabytes per core, for databases that benefit from large caches. Memory matters because the engine keeps recently used data pages in memory, so more memory often means fewer slow disk reads.

Sizes

Instances come in steps of cores, such as four, eight, sixteen, twenty-four, thirty-two, forty, sixty-four and eighty, with smaller sizes available through instance pools. You also reserve storage separately, up to a maximum that depends on the tier and size, and you can usually grow it later. There are limits on the number of databases per instance and on log throughput, so check the current limits table when sizing.

The picture below shows how a managed instance sits inside your network and how the management side of Azure reaches it.

flowchart LR
  subgraph VNET["Your virtual network"]
    APP["Applications and tools"]
    subgraph SUB["Dedicated delegated subnet"]
      GW["Gateway nodes"]
      subgraph VC["Virtual cluster"]
        N1["Node with SQL engine: instance A"]
        N2["Node with SQL engine: instance B"]
      end
    end
  end
  ONP["On premises network via VPN or ExpressRoute"] --> GW
  APP -->|"Private endpoint on port 1433"| GW
  GW --> N1
  GW --> N2
  N1 --> ST["Azure storage for data, log and backups"]
  MGMT["Azure control plane and management service"] -.->|"Managed through a management endpoint"| VC
  PUB["Optional public endpoint on port 3342"] -.-> GW

The virtual cluster

When you create the first instance in a subnet, Azure builds a virtual cluster there, a group of machines it owns and runs. Your instances are placed on these machines, and their data is stored on the storage that matches the tier. You cannot sign in to the machines; you see only the instance. Later instances in the same subnet can reuse the same cluster, which makes them faster to create than the first.

The gateway

Applications connect to the instance’s host name, which resolves to a private address in your subnet. A gateway layer accepts the connection, checks it and finds the node currently hosting the instance. After a failover or a move, the gateway directs new connections to the new location, so the host name never changes. Connections inside your network can be redirected to talk to the node directly for lower delay, while connections that arrive across certain network paths use the proxy mode where the gateway stays in the middle.

The management plane

Azure needs to reach the cluster to create, update, back up and heal it. It does this through a dedicated management endpoint, which is why the subnet must allow certain traffic and must be delegated to the service. Modern deployments use intent-based network rules, where the service itself maintains the required route and security rules on the subnet, rather than leaving every rule to you. Putting your own unrelated resources in that subnet, or removing the managed rules, can break operations.

Storage and backups

Data files live on Azure storage in General Purpose, or on local disk in Business Critical. In both tiers, automated backups are written to separate Azure storage with the redundancy you choose. This means a failed node does not take backups with it, and a restore can happen on a different node entirely.

Networking is the part of Managed Instance that surprises newcomers most, and the part where early mistakes are most expensive. Understand it first and everything else becomes easier.

Why a dedicated subnet

Unlike Azure SQL Database, which is reached through a public service address, a managed instance is deployed into your virtual network and receives a private IP address from your own address range. This is what makes it feel like a server in your own data center: on-premises systems, other Azure resources and virtual machines reach it over private paths, and nothing on the public internet can touch it unless you choose to allow that. The cost of this closeness is planning. The instance needs its own subnet, and that subnet needs enough free addresses to host the cluster now and to grow later. The documented minimum size is small, around thirty-two addresses, but larger subnets give room for more instances and for service operations that temporarily need extra addresses.

Subnet rules

The subnet must be delegated to the managed instance service, which gives Azure permission to configure it. It must not hold other types of resources. It needs a route table and a network security group, and in the modern model these are maintained by the service itself so that the management traffic can always flow. Your job is to add your own rules around them, for example to control which application subnets may connect to the instance, never to delete the rules Azure created.

Endpoints

flowchart TD
  subgraph HUB["Hub virtual network"]
    FW["Firewall and DNS"]
    VPN["VPN or ExpressRoute gateway"]
  end
  subgraph APPNET["Application virtual network"]
    WEB["App service or virtual machines"]
  end
  subgraph MINET["Managed instance virtual network"]
    MI["Managed instance in delegated subnet"]
  end
  CORP["On premises data center"] --> VPN
  VPN --> FW
  WEB -->|"VNet peering"| FW
  FW -->|"VNet peering"| MI
  WEB -.->|"Direct peering when allowed"| MI

Connecting from other places

Applications in the same virtual network connect directly. Applications in other virtual networks connect through virtual network peering, which links two networks so they can talk privately. Offices and data centers connect through a VPN gateway or a dedicated ExpressRoute circuit. Services such as Azure App Service can reach the instance through a network integration feature that places their outbound traffic inside your network. For each path, name resolution matters. The instance’s host name includes a unique DNS zone identifier, and every network that connects must resolve that name to the private address, either through Azure private DNS or through forwarding in your own DNS servers.

Network rules you will write

A managed instance runs the same engine family as SQL Server, so knowing a few engine ideas explains most performance behavior.

From text to answer

When you send a query, the engine parses it, then asks the query optimizer to build a plan: a recipe that says which indexes to use, in what order to join tables and how to sort. The optimizer chooses by consulting statistics, small summaries of how values are distributed in each column. The plan is cached and reused. The executor then runs the plan, reading data pages and returning rows. When statistics are stale the optimizer can choose a poor plan, so the engine keeps them fresh automatically.

Memory, pages and the buffer pool

Data is stored in eight kilobyte pages. Recently used pages are kept in a memory area called the buffer pool. A read served from memory is far faster than one that must fetch from storage. This is why memory per core is one of the key choices of hardware generation, and why good indexes, which reduce the pages a query must touch, are so valuable.

Write-ahead logging

Changes are first written to the transaction log, and the commit is confirmed only after that record is safely stored. The changed data pages are written to the data files later in the background. After a crash, the engine replays the log to redo committed changes and undo unfinished ones. Because of this rule a confirmed transaction survives failures. Managed Instance also uses accelerated database recovery, which makes recovery and rollback fast even after very long transactions.

Locks and row versions

When many people work at once, the engine uses locks to stop conflicting changes. A database can also use row versioning, keeping older copies of rows so readers see a consistent snapshot and do not wait for writers. In Managed Instance, as in the cloud database service, new databases use read committed snapshot isolation by default, though a database restored from an older server keeps the setting it had. If your source application depended on classic locking behavior, check this setting during migration.

tempdb: the shared scratch area

Every query that sorts large results, builds temporary tables or uses row versions touches tempdb. It is shared by all databases in the instance, so one greedy query can slow its neighbors. In Managed Instance, tempdb lives on fast local disk, and its size is tied to the instance size. Watch it in monitoring, and avoid designs that create huge temporary tables.

Query Store and automatic tuning

The Query Store records the plans and run-time statistics of queries, creating a history you can compare week to week. With it, the engine can spot a plan regression, when a query suddenly slows because a worse plan was chosen, and the automatic tuning feature can force the earlier good plan back. Query Store is on by default for new databases but may be off in a database that was restored from an old server, so enable it deliberately.

Compatibility levels and update policy

Each database has a compatibility level that controls which optimizer and language behaviors it follows. Restored databases keep their old level until you raise it. Managed Instance also has an update policy choice: one policy keeps the instance on the newest engine features as Microsoft releases them, while another pins the available feature set to a specific SQL Server release such as 2022, so behavior stays predictable. Pick the one that fits how fast your team can test changes.

Two timelines matter. The short one is a single transaction. The long one is the life of the instance itself, from creation through updates to deletion.

sequenceDiagram
  participant App as Application
  participant GW as Gateway
  participant P as Primary node
  participant S as Secondary replicas
  App->>GW: Connect to instance host name and sign in
  GW->>P: Route the session
  App->>P: Begin transaction, change rows in two databases
  P->>P: Write log records
  P->>S: Send log records in Business Critical
  S-->>P: Acknowledge hardened log
  P-->>App: Commit confirmed
  P->>P: Flush data pages later
  Note over P,S: One transaction can span databases on the same instance

A transaction that crosses databases

One of the biggest reasons people choose Managed Instance is that a single transaction can change several databases on the same instance and still be atomic: all of it commits or none does. Reports can join tables across databases in one statement. In Azure SQL Database this is limited, and applications would need redesign. On a managed instance it simply works, just like on a server.

Step by step

The life of the instance: management operations

Creating, scaling, changing tiers, updating and deleting an instance are management operations. They run in the background and can take a long time. Creating the first instance in a new subnet may take hours because the virtual cluster has to be built. Adding another instance to an existing cluster is quicker. Scaling cores or storage can take minutes to hours depending on what must move. During many operations the instance stays online and then switches over at the end, causing a short disconnect, so retry logic is still required. Only one major operation runs at a time on an instance, and some operations queue behind others, so schedule changes with patience.

Maintenance and updates

Azure applies engine and platform updates automatically. You do not choose to install a patch, but you can set a maintenance window, a recurring time such as weekday nights or weekends, in which planned maintenance is allowed to happen. Unplanned events, such as a hardware fault, are handled at any time. After a maintenance step, your application will see a brief reconnect, which is why short, well-tested retry code is not optional.

Stopping and deleting

Because compute is billed while the instance exists, unused instances should be removed or, where the platform offers it, stopped. Deleting an instance deletes its databases, but backups from the retention window may remain available for restore for a time. Always take a final copy before deleting something that might be needed later.

Two questions sit inside “reliable”: what if one machine breaks, and what if a whole region goes dark? Managed Instance answers each with different tools.

Built-in availability

Every instance is protected against machine failure at no extra charge. In General Purpose, a failed node is replaced by a new one that attaches the same storage, usually within a short time. In Business Critical, a secondary replica that is already running takes over almost immediately. The availability service level is 99.99 percent for typical configurations. During a failover, existing connections are dropped and new ones are routed to the new primary, so applications must reconnect.

Zone redundancy

In regions with availability zones, you can enable zone redundancy, which spreads the replicas across separate buildings with independent power and cooling. Losing a whole zone then does not take down the instance. It is a setting on the instance that adds cost but needs no application change, and it should be used for systems where a zone outage would be unacceptable.

Auto-failover groups for region failures

To survive the loss of a region, keep a second managed instance in another region and connect them with an auto-failover group. Data is copied asynchronously from the primary instance to the secondary. The group offers two stable names: a read-write listener that always points to the current primary, and a read-only listener that points to the secondary. When failover occurs, the names move, so connection strings stay the same. Failover can be started manually, or automatically after a grace period you set. The two instances need network connectivity to each other, typically through peering between their virtual networks, and matching DNS zone settings.

The managed instance link

The link feature connects a SQL Server running elsewhere, such as in your data center or on a virtual machine, to a managed instance using the same technology as availability groups. Data flows continuously from the source to the instance. This can be used to migrate with minimal downtime, to offload reporting to Azure, or as a disaster recovery site for an on-premises server. For certain versions, a failover can even move back from Azure to SQL Server. Supported source versions and rules change over time, so verify them before planning.

flowchart LR
  subgraph R1["Primary region"]
    MI1["Primary managed instance with zone redundancy"]
  end
  subgraph R2["Secondary region"]
    MI2["Secondary managed instance readable"]
  end
  APP["Application"] -->|"Read write listener"| FG["Auto failover group endpoints"]
  RPT["Reporting"] -->|"Read only listener"| FG
  FG --> MI1
  FG -.-> MI2
  MI1 -.->|"Asynchronous replication"| MI2
  SQL["On premises SQL Server"] -.->|"Managed instance link"| MI1

Backups are automatic and need no schedule from you. What you decide is how long they are kept, where copies live and how you restore from them.

The automatic chain

The service takes full backups about weekly, differential backups every twelve hours or so, and transaction log backups every few minutes. Together they allow restoring a database to nearly any second within the retention period, called point-in-time restore. The short-term retention window is seven days by default and can be set between one and thirty-five. For longer needs, long-term retention keeps weekly, monthly and yearly full backups for up to ten years, which helps with audit and legal rules.

Where backups live

Backups are stored in storage managed by Azure, with redundancy you choose: local, zone, geo or geo-zone. Geo-redundant backups are copied to the paired region and make geo-restore possible if the home region is lost and no secondary instance exists. Backup storage up to the size of your reserved instance storage is generally included, and more is billed.

Restore creates something new

A point-in-time restore does not overwrite the existing database. It creates a new database on the same instance, or on another instance in the same region, at the moment you choose. You then inspect it, copy back the rows you need or swap names. This is safer, since a wrong choice of time can simply be repeated. It also means you need free storage and, for large restores, patience.

Native backups you control

Unlike the cloud database service, a managed instance also supports ordinary SQL Server backup commands, with some limits. You can take copy-only backups to Azure Blob Storage and restore databases from backups that sit in storage. This makes it possible to bring a database from an on-premises server by restoring a backup file, and to send a copy back out for a developer to inspect. The automatic backups remain in service control, and you cannot delete them, but your own copy-only backups are yours.

The strongest argument for Managed Instance is a list of abilities that live at the instance level and are missing or limited in single cloud databases. This chapter walks through the most important ones.

SQL Server Agent: scheduled jobs

The SQL Server Agent runs jobs on a timetable: nightly index maintenance, data loads, report generation, cleanup. Jobs are made of steps, can send alerts, and are stored in the msdb database. Managed Instance supports the agent, so existing job definitions can be scripted from the old server and recreated, with some changes where steps relied on things that no longer exist, such as local file paths or operating system commands.

Cross-database queries and transactions

Many applications split data over several databases on the same server: one for customers, one for orders, one for reporting. A query can name tables from several of them, and a transaction can change them together. On a managed instance this works unchanged, as the databases share the instance. This single feature saves months of redesign for large legacy systems.

Linked servers and distributed transactions

A linked server lets a query read from another database system as if it were local. Managed Instance supports linked servers to other managed instances and to SQL Server, with restrictions on the sign-in methods and other target types. For transactions that must span instances, a server trust group can be set up between instances so that distributed transactions can commit across them.

Database Mail, Service Broker and CLR

Database Mail sends email from inside the database, for example order confirmations or alerts. Service Broker provides reliable message queues inside the database, within one instance. CLR integration lets you run compiled .NET code as database functions, though in a managed service it runs with restrictions and cannot touch the file system. If your old system used any of these, check each use against current support notes.

Replication and Machine Learning Services

Managed Instance can take part in transactional replication, as a publisher, distributor or subscriber, which helps migrate or synchronize data with other servers. It also offers Machine Learning Services for running R and Python scripts next to the data, so models can score rows without moving them out.

Server-level settings and logins

Because it is an instance, you manage server-level logins, server roles, credentials, linked server definitions and the instance’s own configuration options. Many applications connect with an instance login and expect it to exist. Migrating those logins, with their permissions, is part of any move.

What remains missing

A short list of items still does not carry over. There is no access to the operating system or the file system, so jobs that run command-line programs or write to local disks must change. Some rarely used features, such as FILESTREAM for storing files in the file system, are not supported. Some instance settings are fixed by the platform. Always run an assessment tool against your source server to list the exact items that apply to you.

A database holds the most valuable data in a company, so it deserves several independent locks. Each layer below assumes the previous one may fail.

Layer 1: the network

The strongest protection of a managed instance is that it lives on a private address inside your virtual network. By default nothing from the public internet can reach it. Access is controlled by the network security group on its subnet, by the routes and firewalls in your network design, and by which networks you connect through peering, VPN or ExpressRoute. If you enable the public endpoint, restrict it to named source addresses and review it often. Many organizations leave it off entirely.

Layer 2: authentication

Managed Instance supports SQL authentication with logins and passwords, as old applications expect. It also supports Microsoft Entra authentication, which uses the company’s central identity system: people sign in with their normal account and multi-factor prompts, and removing a person from the directory removes their access. Applications running in Azure can use a managed identity, which proves who they are without any stored password. An Entra-only setting can switch off SQL logins when you are ready. Where legacy applications need Windows-style sign-in, check the current options for Kerberos-based authentication with Entra identities.

Layer 3: authorization

Authorization decides what each identity may do. Server roles and database roles give broad rights, and permissions on tables, views and stored procedures give narrow ones. Follow the principle of least privilege: the application account gets only what it needs. Row-level security filters rows by who is asking. Dynamic data masking hides parts of sensitive values for users without special permission.

Layer 4: encryption

Transparent data encryption, or TDE, encrypts data files, logs and backups at rest and is on by default. Keys can be service-managed or customer-managed in Azure Key Vault, which lets you rotate or revoke them. Connections use TLS, and you can require a minimum version. Always Encrypted protects chosen columns so that even administrators see only scrambled values, because the application holds the keys. Ledger tables add a cryptographic record that proves history has not been quietly changed.

Layer 5: auditing and detection

SQL Audit records events such as sign-ins, queries and permission changes to storage, a log analytics workspace or an event hub. Microsoft Defender for SQL adds vulnerability assessment, which scans for risky settings, and threat detection, which warns of unusual access or injection attempts. Data discovery and classification labels columns holding personal or financial data.

A managed instance slows down for only a few reasons: too little compute or memory, too much work per query, waiting on locks, or a slow path to storage. Sizing treats the first; good design treats the rest.

Scaling up and down

You change the number of cores, the tier or the reserved storage through a management operation. The instance usually stays online until a final switch, which drops connections briefly. Operations take longer than scaling a single database, so plan ahead and avoid resizing as a reaction to a sudden spike. Storage can generally grow, but shrinking is limited, so reserve with some headroom, not too much, because you pay for what you reserve.

Input and output speed in General Purpose

In the classic General Purpose design, the speed of each data or log file depends on the size of that file, because storage performance is tied to size. A database with many small files can show surprisingly low throughput compared with its total size. Teams sometimes fix this by making files larger, by consolidating them, or by moving the busiest databases to Business Critical, which uses local disks and does not have this effect. Read the current documentation, since newer General Purpose options change the rules.

Memory and the cache

The buffer pool holds hot pages. If the working set is bigger than memory, the engine keeps fetching pages from storage and everything slows. A higher memory-per-core hardware family is often cheaper than adding cores, if the real problem is cache misses. Metrics for page life and for read activity will tell which situation you are in.

Scaling out reads

In Business Critical, one built-in secondary replica accepts read-only connections when the connection string says the intent is read only. Reports and exports can use it, keeping the primary free for transactions. An auto-failover group’s read-only listener gives a similar benefit from the secondary region, with a short delay in freshness.

Queries come first

The worst slowdowns are often self-inflicted. Missing or unused indexes, fetching more columns than needed, running one query per row inside a loop and mismatched data types that block index use are the usual suspects. Fixing the top query often reduces load more than doubling the cores.

A worked sizing example

A company wants to consolidate 40 databases from two old servers onto one managed instance. Monitoring over a month shows the databases together average 10 cores of CPU use. At the busiest hour of the month end, the combined peak reaches 18 cores. They add 25 percent headroom, giving 22.5 cores. The next available size is 24 cores. On the standard hardware family with about 5.1 gigabytes of memory per core, that is roughly 122 gigabytes of memory, which they compare with the combined working set of their hot data. Storage: the databases total 2.4 terabytes, so with 30 percent growth planned over the next year they reserve about 3.1 terabytes and review it every quarter. Notice that they sized for the combined peak, not for the sum of each database’s individual peak, which would be many times larger.

Four views answer almost every question: what the platform measures, what the engine remembers, what the logs say, and what alerts tell you before users do.

Platform metrics

Azure Monitor shows numbers for each instance without any setup: average CPU percentage, storage space used and reserved, input and output requests and bytes, and, for the tier, measures such as log write rate. You can chart them, build dashboards and set alerts. Because the instance is shared by many databases, a single high number may come from one of them, so drill in with the engine’s own views.

Engine-level insight

The engine’s dynamic management views, called DMVs, show running requests, waiting tasks, blocking chains, memory use and index usage. The Query Store keeps the history of plans and runtime numbers per database. Extended Events capture detailed events for short investigations. Intelligent Insights and tuning recommendations point to patterns like regressions or resource limits. If you used SQL Server tools before, most of them work the same way.

Logs and auditing

Diagnostic settings can stream resource usage statistics, errors and, through SQL Audit, security events into a Log Analytics workspace, a storage account or an event hub. Send audit data to a protected location so an intruder cannot erase their own tracks. The errorlog and the history stored in msdb also remain available for jobs and backups.

Alerts that matter

A calm way to investigate slowness

The monthly cost is built from a few meters. If you know them, you can predict, reduce and explain the bill.

Ways to pay less

Right-size from real data and review it often. Apply the Azure Hybrid Benefit if you own SQL Server licenses with Software Assurance, which can cut the compute price substantially. Buy reserved capacity for one or three years for steady production instances. Use General Purpose unless you truly need Business Critical. Consolidate small databases onto fewer instances, and use instance pools for small instances. Remove abandoned test instances, and reduce retention on non-critical data. Microsoft has also offered limited free trials for new instances; check the current terms before relying on them.

A worked cost example

The prices below are made-up round numbers to show the shape of the saving. Take a General Purpose instance with 8 cores, running all month, 730 hours. If the license is included at 0.45 dollars per core-hour, compute costs 8 times 0.45 times 730, which is 2,628 dollars. With Azure Hybrid Benefit the rate falls to 0.20 per core-hour, giving 8 times 0.20 times 730, or 1,168 dollars, a saving of about 55 percent. Now add a three-year reservation worth, say, a further 30 percent off that rate, and the figure drops to about 818 dollars. The workload and the instance did not change at all; only the way it is paid for did.

Beware of idle instances

A managed instance bills while it exists. A developer instance that sits unused for the weekend costs as much as one running a heavy report. Where the service offers a stop and start capability, use it for non-production instances, and check availability and terms. Otherwise delete and recreate from a restore when needed, remembering that creation can take a while.

Migration is the main reason most teams meet Managed Instance. The good news is that there are several well-trodden paths. The skill is choosing one that matches your database size and your tolerance for downtime.

Step zero: assess

Before moving anything, run Microsoft’s assessment tools against the source server. They list features in use, flag the ones that are unsupported or changed, estimate the instance size and sometimes suggest a tier. Treat the report as a to-do list. Common findings are jobs that call the operating system, references to local file paths, old compatibility levels, and server-level settings that must be recreated.

The main paths

flowchart LR
  SRC["Source SQL Server"] -->|"1 Full backup"| BLOB["Azure Blob Storage"]
  SRC -->|"2 Continuous log backups"| BLOB
  BLOB -->|"3 Restore and replay"| LRS["Log Replay Service on managed instance"]
  LRS -->|"4 Stay in restoring state"| DB["Target database restoring"]
  CUT["Cutover: stop writes, last log backup"] --> LRS
  LRS -->|"5 Complete"| LIVE["Database online and writable"]
  APP["Applications"] -.->|"6 Switch connection string"| LIVE

Moving the instance-level pieces

Databases are only half of the move. You must also carry across the logins and their permissions, the agent jobs and schedules, the alerts and operators, the linked server definitions, the Database Mail profiles and any server-level settings that the application relies on. Script these from the source and recreate them. Test every job once on the new instance, because jobs that worked for years may fail silently on the first run.

A migration plan in order

A fair look at strengths and limits helps you decide when Managed Instance is right and when its neighbors are better.

How it compares with nearby choices

The three main trade-offs

Compatibility versus convenience. More instance features mean more things to move, test and own. Isolation versus cost. One instance with many databases is cheaper, but they share resources; several smaller instances isolate better and cost more. Agility versus control. A managed service removes chores but also removes the ability to tune the operating system, so decisions you could once make with a command line now have to fit the platform’s rules.

A small set of shapes appears in healthy Managed Instance deployments, and a small set of mistakes appears in the unhealthy ones.

Patterns that work

Anti-patterns to avoid

These habits come from teams that have moved and run instances in production. Most cost little and prevent most painful stories.

Common mistakes

Failures come from hardware, software, people and attackers. The table pairs the usual ones with a first response.

Recovery objectives in plain words

Two numbers guide a plan. The recovery point objective is how much recent data you can afford to lose, measured in time. The recovery time objective is how long the system may be unavailable. Zone redundancy offers near-zero loss and a fast switch. An auto-failover group offers seconds of possible loss and minutes of switch time. Backups offer a flexible point in time but a longer restore. Write both numbers down for each system, then pick the cheapest combination that meets them.

Failing over with confidence

Five common situations show how the ideas combine. Figures are illustrative, not from a particular customer.

Short answers to the questions people ask most when they first meet Azure SQL Managed Instance.