Within Azure, we have a few options to run our SQL Databases. We have Azure SQL Data Warehouse, which is built for large scale, big data relational databases. We can also run our SQL on Azure SQL VMs, where we can gain benefits by doing this within Azure compared to running them on VMWare or Hyper Feed.
But today I want to focus on Azure SQL Database and the some of its pros and cons to help you to see if it’s a good fit for your data. First off, Azure SQL DB is a Platform as a Service (PaaS) offering in Azure that gives you an Azure SQL Database in the cloud. With PaaS, we get somewhat of a serverless infrastructure; relieving you of having to maintain that server. All you have to worry about is the databases; no worries about patching SQL Server or windows servers, that is all handled on the backend by Microsoft.
From that perspective, it’s a great opportunity for lowering your maintenance cost, as well as cut back on time you spend on maintenance chores with patching schedules. Another benefit is that Microsoft is rolling out some new features that we don’t get in our usual SQL environment. Things like point and click geo replication. Sure, you can script this out through PowerShell, but with this you can go within the Azure portal, and with a few clicks, you can point your database to a secondary and it will automatically set up replication to that secondary database in another Azure region.
So, we’re covered for things like doing reads from the West coast while our office is in the East coast; we can do reads from multiple offices with some lower latency. It also covers some disaster recovery scenarios, whereas if a disaster happens to the Azure data center in the East, we’d have it replicated in the West.
We also get benefits like backups being set up for us automatically and much easier to maintain. We get index tuning advisor, which will monitor our workloads and suggest indexes that can help improve the performance of our Azure SQL DB.
Something that may hold you back from initially using it would be the fact that because you’re not maintaining a server or a SQL instance, you will not have the capabilities of some of the features that are at that level of the SQL system. Things like setting up link servers, CLRs and you don’t have a SQL agent anymore. You’ll need to use something else like Runbooks within Azure to schedule those jobs.
So, if this is something you know and love and have a heavy reliance on, it may hold you back from jumping into Azure SQL DB, but definitely something you should make part of your future plans.
That’s a brief intro into Azure SQL Database. Take a look for yourself as it’s a great option in some scenarios, but with a few hiccups to watch out for. If you need help sorting through those gotchas and want to learn how to take advantage of the pros of this in your environment, click the link below or contact us—we’re here to help.