After many years working with different “flavours” of SQL server in Azure from its true PaaS form to SQL server in AKS (Azure Kubernetes Service) it’s time to look at SQL Managed Instances – you will notice that I call it SQL MI.
Why? Quite simply you want and have the need for your instance level design to be in Azure. Yes, you can build a VM as an IaaS approach but SQL MI is the sweet spot between having that instance level functionality with all the benefits of a PaaS system like Azure SQL Database – think things like built-in backups, SQL updates and H/A all done for you.
What can SQL MI do that Azure SQL DB cannot? If you need:
- Cross database query / transaction.
- Service Broker.
- SQL agent jobs.
Then this is the way forward.
There are more but I think of the above as the main reasons. There are many key decisions to make when building this data solution and is something I intend on covering over time such as from What tier to use – General Purpose vs Business Critical to moving data via native backups. Sometimes there might also be a resource limit meaning that you stick with Azure SQL VMs – hopefully not but it’s still possible, you may need more than 80vCores or it may not be cost effective.
So, Stay tuned.