Times are a-changing, and the past couple of months have witnessed a flurry of activity on the cloud computing front; namely, SQL Azure and Amazon RDS. Touted as the harbingers of a new era — the era of Relational DBMS-as-a-Service (DBaaS) — these latest offerings pointedly reassert the fact that databases are now part of the utility model of cloud computing.
For those planning on an early adoption, even with just two significant products (no one seems to have noticed Joyent’s Accelerator for MySQL), it could get really difficult to choose. Here’s a list of 5 things that will help you make the right choice.
1. Target Customers: Microsoft’s target for SQL Azure (based on extensive research) is business applications running in the enterprise using databases of 5GB or less. Amazon RDS, comparatively, is more flexible and targets a larger segment of users. While with SQL Azure, you can have a database of up to 10GB, Amazon RDS allows storage of up to 1TB per database instance. Microsoft advises sharding your data in case your requirement exceeds the 10GB limit, which is not really a bad idea: Sharding your data across multiple servers will scale much better than having it all on one bloated server.
2. Support for the Cloud Platform: SQL Azure is “native” to the cloud platform. What does this mean? While MySQL (which is what Amazon RDS provisions) is cloud-capable (i.e., can be run on a cloud system without issues), SQL Azure was designed, from scratch, specifically for it. This can only mean that SQL Azure is poised to utilize the resources available in a cloud explicitly.
3. Deployment: This is where SQL Azure and Amazon RDS differ the most. While many other bloggers may lead you to believe otherwise, SQL Azure doesn’t have the concept of server/database “instances”. The “servers” that you create are more logical containers than anything else. These containers are provisioned for you exclusively, and will only host your databases. There is a one-to-many relationship between a physical node in the cloud and the servers users create — several servers created by different users may be hosted on the same hardware platform in a shared environment. That is the multi-tenanted architecture implemented by SQL Azure. However, Microsoft doesn’t plan on releasing more specifics about how servers are deployed. The biggest advantage of this model is that Microsoft is able to provide SQL Azure at very low rates. On the flip side, performance enthusiasts do not get the opportunity to tailor the system to their needs. For instance, you cannot change the cache size of your database. Moreover, having a 10GB maximum limit forces a design decision on applications that require large databases. (As previously mentioned, Microsoft advises sharding — partitioning — your data into multiple databases.)
So, how is Amazon RDS different? If you look closely enough, Amazon RDS also implements a multi-tenanted architecture (it’s highly improbable that they could afford to have a separate hardware set up for each user!). But this model is implemented at a very different level than that of SQL Azure’s. Amazon RDS provisions a specialized EC2 instance to your AWS account. You can then create multiple, highly varied, instances of MySQL on that EC2 instance. Database instances can vary on the basis of storage (up to an astronomical 1TB) and compute resources (up to 26 ECUs and 68GB of RAM), and you have complete control of your DB parameters (which can be changed using the APIs exposed by Amazon RDS).
4. Compatibility with Existing Systems: For the time being at least, SQL Azure supports only a subset of the features available in SQL Server. On the other hand, Amazon RDS flaunts complete support for MySQL features minus replication. If you are a fan of MySQL, chances are that your applications will work seamlessly with Amazon RDS as well. For instance, in one of my previous posts, I had described how to set up SQLyog and MONyog for an Amazon RDS DB instance. SQL Azure features support for Transact-SQL, and existing libraries — ADO .NET, ODBC and PHP — for connection.
5. Cost/Features Ratio: With all its limitations as compared to Amazon RDS, SQL Azure is definitely a cheaper solution. A notable feature in SQL Azure is that databases are automatically replicated across multiple systems providing for read scale-outs as well as a transparent fail-over mechanism in case of hardware failure — all this while Amazon RDS has specifically disabled replication on its MySQL instances. Then again, SQL Azure doesn’t feature a parallel to the unique on-demand snapshot-based backup method offered by Amazon RDS. Data in SQL Azure is automatically backed up and restored when a disaster occurs. This is transparent to the user. Users will only experience the ‘high availability’ that this feature implies.
One last thought… So, which is it: SQL Azure or Amazon RDS? In my opinion, that would depend entirely on the type of technology you use. If you’re primarily a Microsoft shop, then SQL Azure will be a better choice, as the technology would be familiar — you’ll get Visual Studio integration, support for .NET applications, T-SQL, etc. On the other hand, if you’re a LAMP shop, then Amazon RDS is definitely the way to go.
Shifting to a more opinionated tone, I’d like to pose this question: What could be the primary motivation behind wanting to move one’s database to the cloud? The answer, undeniably, is scalability. As your business grows, so does your database (or so they say!). While on the surface Amazon RDS looks very glossy — they have oh-so-many features, and customizations, and options — under the hood, it boils down to one thing. Amazon RDS database instances have limited scaling capability: If you create a Double Extra Large DB Instance, and you need more compute resources (ie, CPU and memory), you’ll have to change the instance type to Quadruple Extra Large and restart your database for it to take effect. What’s more, if you’ve created a Quadruple Extra Large DB instance, and your DB instance is not actually using all of the resources available, you’ll still be paying through your nose for it! SQL Azure on the other hand, allows unlimited scaling at no extra cost. All you pay for is the increased data transfer.
Conversely, SQL Azure allows only up to 10GB storage. How weird is that? My PC has a database of 14GB, which I only use for testing! If you want more storage, create a new database, shard your data across the two databases, and possibly pay double the price — all when you just needed a couple of GBs extra? Phew! I’m glad I won’t be needing to hire either Amazon’s or Microsoft’s services for a while now!