We have come a long way in five years, but there’s always room to do better! The database engines that I listed above were designed to function in a constrained and somewhat simplistic hardware environment — a constrained network, a handful of processors, a spinning disk or two, and limited opportunities for parallel processing or a large number of concurrent I/O operations.

The RDS team decided to take a fresh look at the problem and to create a relational database designed for the cloud. Starting from a freshly scrubbed white board, they set as their goal a material improvement in the price-performance ratio and the overall scalability and reliability of existing open source and commercial database engines. They quickly realized that they had a unique opportunity to create an efficient, integrated design that encompassed the storage, network, compute, system software, and database software, purpose-built to handle demanding database workloads. This new design gave them the ability to take advantage of modern, commodity hardware and to eliminate bottlenecks caused by I/O waits and by lock contention between database processes. It turned out that they were able to increase availability while also driving far more throughput than before.

Amazon Aurora – New MySQL-Compatible Database Engine Today we are launching Aurora, is a fully-managed, MySQL-compatible, relational database engine that combines the speed and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases.

When you use Amazon Aurora, you’ll spend less time managing and tuning your database, leaving you with more time to focus on building your application and your business. As your business grows, Amazon Aurora will scale with you. You won’t need to take your application off line in order to add storage. Instead, Amazon Aurora will add storage in 10 GB increments on as as-needed basis, all the way up to 64 TB. Baseline storage performance is rapid, reliable and predictable—it scales linearly as you store more data, and allows you to burst to higher rates on occasion. You can scale the instance size in minutes and you can add replicas with a couple of clicks.

Storage is automatically replicated across three AWS Availability Zones (AZs) for durability and high availability, with two copies of the data in each Availability Zone. This two-dimensional redundancy (within and across Availability Zones) allows Amazon Aurora to make use of quorum writes. Instead of waiting for all writes to finish before proceeding, Amazon Aurora can move ahead as soon as at least 4 of 6 writes are complete. Storage is allocated in 10 GB blocks distributed across a large array of SSD-powered storage. This eliminates hot spots and allows for a very high degree of concurrent access, while also being amenable to self-healing. In fact, Amazon Aurora can tolerate the loss of two copies of the data while it is handling writes and three copies of the data while it is handling reads. This scatter-write model also allows for very efficient and rapid backup to Amazon Simple Storage Service (S3). Because the writes take advantage of any available free space, backups are highly parallelized and do not impose any load on the database instance. In the event that a database instance fails, Amazon Aurora will make an attempt to recover to a healthy AZ with no data loss. Amazon Aurora also makes continuous, instantaneous backups. You can use these backups to restore your database to a previous state with one-second granularity (restoration would only be necessary if there were no replicas in any of the other Availability Zones).

Amazon Aurora is designed for 99.99% availability. It will automatically recover from instance and storage failures. You can create up to 15 Amazon Aurora replicas to increase read throughput and for use as failover targets. The replicas share storage with the primary instance and as such provide lightweight, fine-grained replication that is almost synchronous (there’s a very modest lag, on the order of 10-20 milliseconds, due to page caching in the replicas).

Your existing MySQL applications will most likely work without changes. If you are using Amazon RDS for MySQL, you can migrate to Amazon Aurora with a couple of clicks. Aurora is feature-compatible with version 5.6 of MySQL.

Then I choose a Database Instance type, name the database, and configure an account for the DBA:

The final step is to set a few advanced details:

I don’t need to tell Amazon Aurora how much storage I need. Instead, the new storage engine will automatically and transparently allocate storage in 10 GB increments as I create and populate tables. The tables that I create in Amazon Aurora must use the InnoDB engine, and I will pay only for the storage that I actually use.

Once the instance is ready (generally less than 10 minutes) the endpoint is available in the console for use in my MySQL client code:

RDS Console Upgrades The Console has been upgraded and now makes additional information about each of my instances available on a set of tabs (Alarms and Events, Configuration Details, and DB Cluster Details). Here’s the first one:

The Console also includes some additional monitoring options for my instances:

I can even expand the monitoring page to fill the screen (this is perfect for display on a big monitor in my operations room):

Pricing and Availability Amazon Aurora was designed to provide you with a price to performance ratio that is more than 4 times better than previously available. When you migrate your existing RDS for MySQL database to RDS for Amazon Aurora you will likely find that you can achieve the same performance with a smaller database instance. Even better, with Amazon Aurora you pay only for the storage that you use.

We are launching Amazon Aurora in preview form in the US East (Northern Virginia) Region. If you are interested in joining the preview, simply click here and fill in the form.