Database restore performance oddities of SQL Server RDS

One of the things I’ve learned over the years is, that sometimes the performance in cloud platforms can be unpredictable and you always need to expect the unexpected. Most of the times these issues are just minor annoyances, but they can certainly be confusing the first time you run into any of them.

A while back I had one of these experiences as I was working with moving databases from on premises datacenter to AWS using the native restore and backup capability in RDS. It’s a really nice feature giving you ability to easily move data in and out from the RDS, using familiar tools for DBAs. However this time I ran into a weirdest issue with the initial restore performance.


Comparing SQL Server deployment options between Azure and AWS

Lately I’ve been spending lot of time outside my natural habitat, Azure, and I’ve entered the AWS frontier. Because of this I decided to write down some of my experiences about how the SQL Server deployments between these two cloud platforms compare to each other. AWS has been around longer than Azure by few years and is the largest of all the public cloud platforms, and I believe, that even today it’s hosting greater number of Windows based VMs than Azure.

With Azure Microsoft had the opposite approach to hosting SQL Server databases, and rather than starting with VMs they first released Azure SQL Database and then later on Microsoft added support for SQL Servers in VMs to attract more of the existing workloads into Azure. Noting the different approaches, let’s then take a look at how they compare when it comes to SQL Server deployments.

The competition of the cloudy giants