If you have an application that will probably require a database engine or database solution like SQL, and probably your solution is being deployed within Azure environment, there's no need of creating a new server, probably a server instances, such as a virtual machine within your Azure environment, and then probably install or start installing a new SQL on it. It is a little bit cumbersome when it comes to manageability. You don't need to, you have to take the headache off yourself because Microsoft has a complete solution already, which is Azure SQL Managed Instance, within the Azure infrastructure, whereby you can deploy your SQL instances and then point your solution to it and then it's scalable. You can start small and then grow big later. It has a lot of advantages. You don't need to worry about the security, you don't need to worry about the patching. Microsoft does that for you. At the same time, you don't really need to worry about the licensing because for instance, if you have a license assurance, you can bring in your license to that environment to reduce the cost. I have been working with automated backups in Azure SQL Managed Instance. Once the instance is being provisioned, I immediately enable the backup on it and then I've been using Azure Backup automation for so many years, which covers both Azure virtual machine, SQL instances and some other solutions within the Azure environment. It is a kind of automation that is very easy to use and then it's going to take care of your environment. Let's say for instance, when it comes to the restore, restoration, probably there's a problem or probably you want to do a kind of restore test. The solution is very, very good. It's capable of doing that because I still remember I've done a lot of restoration within the infrastructure on several occasions. I'm also doing something else too within the environment. I can restore to another geo-location within the Azure environment as well. Let's say for instance, my infrastructure is being provisioned within the West Europe and I want to do a kind of restoration to another geographical location, I can do that. I am working with multi-layered security features in the Azure environment. The company has different departments, the infrastructure team, the IT security teams and then the database team itself. We have some set of people that manage the entire database. My own responsibility is to make it available, provision it, make it available, give access to the database guys and their application guys to work with. When it comes to security, I have my own side of it, while the database guys also have their own side of it, especially when you are talking about the database. It is a shared responsibility. I'm not the only one handling that. We run vulnerability checks on a regular basis, on a quarterly basis, to see if there's anything that we need to probably close within the infrastructure.
My main use case for Azure SQL Managed Instance is for storing information related to insurance and claims in the staging database to avoid using Dataverse because it is more expensive. I use Azure SQL Managed Instance to store claim information, which allows me to save the data there. Typically, I have a retention period of 30 days in my own Dataverse. Once the data is moved from Dataverse to Azure SQL Managed Instance, I immediately delete that data from Dataverse. The retention period in Azure SQL Managed Instance is eight years, and I display that data on Dataverse by using the OData API in the virtual table.
Learn what your peers think about Azure SQL Managed Instance. Get advice and tips from experienced pros sharing their opinions. Updated: September 2026.
Azure SQL Managed Instance is a managed database service that combines the rich SQL Server programming surface area with automated operations like patching, backup, and performance tuning, providing a seamless way to modernize applications with cloud efficiencies.Designed for enterprises looking to migrate to the cloud, Azure SQL Managed Instance offers a high level of compatibility with SQL Server, making it an attractive option for those aiming to move existing applications with minimal...
If you have an application that will probably require a database engine or database solution like SQL, and probably your solution is being deployed within Azure environment, there's no need of creating a new server, probably a server instances, such as a virtual machine within your Azure environment, and then probably install or start installing a new SQL on it. It is a little bit cumbersome when it comes to manageability. You don't need to, you have to take the headache off yourself because Microsoft has a complete solution already, which is Azure SQL Managed Instance, within the Azure infrastructure, whereby you can deploy your SQL instances and then point your solution to it and then it's scalable. You can start small and then grow big later. It has a lot of advantages. You don't need to worry about the security, you don't need to worry about the patching. Microsoft does that for you. At the same time, you don't really need to worry about the licensing because for instance, if you have a license assurance, you can bring in your license to that environment to reduce the cost. I have been working with automated backups in Azure SQL Managed Instance. Once the instance is being provisioned, I immediately enable the backup on it and then I've been using Azure Backup automation for so many years, which covers both Azure virtual machine, SQL instances and some other solutions within the Azure environment. It is a kind of automation that is very easy to use and then it's going to take care of your environment. Let's say for instance, when it comes to the restore, restoration, probably there's a problem or probably you want to do a kind of restore test. The solution is very, very good. It's capable of doing that because I still remember I've done a lot of restoration within the infrastructure on several occasions. I'm also doing something else too within the environment. I can restore to another geo-location within the Azure environment as well. Let's say for instance, my infrastructure is being provisioned within the West Europe and I want to do a kind of restoration to another geographical location, I can do that. I am working with multi-layered security features in the Azure environment. The company has different departments, the infrastructure team, the IT security teams and then the database team itself. We have some set of people that manage the entire database. My own responsibility is to make it available, provision it, make it available, give access to the database guys and their application guys to work with. When it comes to security, I have my own side of it, while the database guys also have their own side of it, especially when you are talking about the database. It is a shared responsibility. I'm not the only one handling that. We run vulnerability checks on a regular basis, on a quarterly basis, to see if there's anything that we need to probably close within the infrastructure.
My main use case for Azure SQL Managed Instance is for storing information related to insurance and claims in the staging database to avoid using Dataverse because it is more expensive. I use Azure SQL Managed Instance to store claim information, which allows me to save the data there. Typically, I have a retention period of 30 days in my own Dataverse. Once the data is moved from Dataverse to Azure SQL Managed Instance, I immediately delete that data from Dataverse. The retention period in Azure SQL Managed Instance is eight years, and I display that data on Dataverse by using the OData API in the virtual table.