Very recently, Amazon (AMZN) subsidiary Amazon Web Services released the Relational Database Service (RDS), serving MySQL databases through their cloud system.

This is AWS’s second database service, the first being the schema-less SimpleDB service, a key-value data storage system. This new service mimics MySQL-like characteristics, and acts just like MySQL, allowing applications to move seamlessly between their current MySQL system to Amazon RDS. The valueadd of the service includes rock-solid reliability (as AWS is known for), high scalability to allow for extremely large datasets, patching of database software to keep up to date, and database backup.

Amazon RDS lists five instance classes available at this time, reproduced below:

• Small DB Instance: 1.7 GB memory, 1 ECU (1 virtual core with 1 ECU), 64-bit platform.
• Large DB Instance: 7.5 GB memory, 4 ECUs (2 virtual cores with 2 ECUs each), 64-bit platform
• Extra Large DB Instance: 15 GB of memory, 8 ECUs (4 virtual cores with 2 ECUs each), 64-bit platform
• Double Extra Large DB Instance: 34 GB of memory, 13 ECUs (4 virtual cores with 3,25 ECUs each), 64-bit platform
• Quadruple Extra Large DB Instance: 68 GB of memory, 26 ECUs (8 virtual cores with 3.25 ECUs each), 64-bit platform

Like most Amazon Web Services offerings, it is on a pay-by-usage model, the lowest being $0.11 per hour of compute instances, plus $0.10/GB/mo of storage and $0.10/million I/O transfer requests.

Amazon Web Services’ current cloud service offerings include Simple Storage System (S3), a scalable cloud file storage system; Elastic Compute Cloud (EC2), scalable computational resources, among other services.

On the AWS RDS marketing page, there is a guide to convert from using one’s own hosted MySQL instance to using an RDS instance. The valueadd of AWS RDS over SimpleDB is clearly defined structured data (versus a schema-less key-value store), and with that comes RDBMS features such as JOIN. However, the rigid schema with RDBMS and RDS makes it less flexible to change.

This could be very disruptive. Hosting databases in the cloud wasn’t an extremely simple thing to do earlier, as the main players in moving a database in the cloud essentially was SimpleDB. Converting an application from using a relational store to using a schema-less system like SimpleDB isn’t a trivial task, especially when JOINs are associated.

Now, however, MySQL databases can now be stored reliably in the cloud, and they scale up in both compute power, storage size, and transfer volume. The bottlenecks surrounding scaling a database to be larger or to crunch more data, fenced in by pre-defined CPU, RAM, or disk limits, is now gone. (Though, of course, you’ll have to upgrade instance classes if you hit that limit.)

The market is very big for such a service: MySQL (now owned by Sun Microsystems, JAVA) powers industry-leading sites such as Google, Nokia, YouTube, Zappos, Yahoo!, among others, and is the database portion of the popular open-source web stack LAMP. It is the most popular open-source database, and holds a market share of 49% in database environments (source: Gartner, Enterprise Databases in an Open Source World). Amazon Web Services could repeat their disruption of files to the cloud with S3, or computing power in the cloud with EC2, again by taking databases into the cloud.

However, RDS opens an important question while on the topic of database speed optimization: it scales up well, great: but how is the performance between webservers and the new RDS storage location? In many cases, webservers access the database on a local or nearby network, which improves performance; however, where is RDS located? Is it mirrored in multiple areas? It’ll work great for EC2, but who knows how well it’ll be for migrating MySQL users.

It’s an open question and we’ll see how it plays out when people mess around with it.