Amazon’s DynamoDB — 10 years later

The idea behind DynamoDB developed from discussions with customers like Don MacAskill, the CEO of SmugMug and Flickr. More and more companies like Don’s were web-based companies, and the number of users online was exploding. The traditional relational database model of storing all the data in a single box was not scaling well. It forced the complexity back on the users to shard their relational databases and then manage all the partitioning and re-partitioning and so forth.

This wasn’t new to us; these challenges are why we built the original Dynamo, but it wasn’t yet a service. It was a software system that Amazon engineers had to operate. At some point in one of our customer advisory board meetings, Don said, ‘You all started Dynamo and showed what is possible with a scalable non-relational database system. Why can’t we have that as an external service?’

All senior AWS executives were there, and honestly it was a question we were asking ourselves at the time. Don wasn’t the only customer asking for it, more and more customers wanted that kind of scalable database where they didn’t have to deal with partitioning and re-partitioning, and they also wanted extreme availability. This led to the genesis of our thinking about what it would take to build a scalable cloud database that wasn’t constrained by the SQL API.

DynamoDB was different from the original Dynamo because it actually exposed several of the original Dynamo components via very easy-to-use cloud controls. Our customers didn’t have to provision clusters anymore. They could just create a table and seamlessly scale it up and down; they didn’t have to deal with any of the operations, or even install a single library to operate a database. This evolution of Dynamo to DynamoDB was important because we truly embraced the cloud, and its elasticity and scalability in an unprecedented manner.

We launched it on January 18^th, 2012 and it was a hit right out of the gate. Don’s company and several others started using it. Right from the launch, not just elasticity, but single-digit latency performance was something that resonated really well with customers. We had innovated quite a bit, all the way from the protocol layer, to the underlying storage layer for SSD storage, and other capabilities that we enabled.

One of the first production projects was a customer with an interesting use case; they were doing a Super Bowl advertisement. Because DynamoDB was extremely elastic it could seamlessly scale up to 100,000 writes a second, and then scale down after the Super Bowl was over so they wouldn’t incur costs anymore. This was a big deal; it wasn’t considered possible at that time. It seems super obvious now, but at that time databases were not that elastic and scalable.

It was a bold vision. But DynamoDB’s built-for-the-cloud architecture made all of these scale-out use cases possible, and that is one of the reasons why DynamoDB now powers multiple high-traffic Amazon sites and systems including Alexa, Amazon.com, and all Amazon fulfillment centers. Last year, over the course of our 66-hour Prime Day, these sources made trillions of API calls and DynamoDB maintained high availability with single-digit millisecond performance, peaking at 89.2 million requests per second.

And since 2012, we have added so many innovations, not just for its underlying availability, durability, security and scale, but ease-of-use features as well.

We’ve gone beyond key value store and now support not just a hash-based partition but also range-based partitioning, and we’ve added support for secondary indexes to enable more complex query capabilities —without compromising on scale or availability.

We also now support scalable change data capture through Amazon Kinesis Data Steams for DynamoDB. One of the things I strongly believe with any database is that it should not be an island; it can’t be a dead end. It should generate streams of what data changed and then use that to bridge it to your analytics applications, or other data stores.

We have continued innovating across the board on features like backup and restore. For a large-scale database system like DynamoDB with millions of partitions, doing backup and restore isn’t easy, and a lot of great innovations went into making this experience easy for customers.

We have also added the ability to do global tables so customers can operate across multiple regions. And then we added the ability to do transactions with DynamoDB, all with an eye on how do you continue to keep DynamoDB’s mission around availability and scalability?

Recently we also launched the ability to reduce the cost of storage with the Amazon DynamoDB Standard Infrequent Access table class. Customers often need to store data long term, and while this older data may be accessed infrequently, it must remain highly available. For example, end users of social media apps rarely access older posts and uploaded images, but the app must ensure that these artifacts are immediately accessible when requested. This infrequently accessed data can represent significant storage expense for customers due to their growing volume and the relatively high cost of storing this data, so customers optimize costs in these cases by writing code to move older, less frequently accessed data from DynamoDB to lower cost storage alternatives like Amazon S3. So at the most recent re:Invent we launched Amazon DynamoDB Standard-Infrequent Access table class, a new cost-efficient table class to store infrequently accessed data, yet maintain the high availability and performance of DynamoDB.

We are on this journey of maintaining the original vision of DynamoDB as the guiding light, but continue to innovate to help customers with use cases around ease of querying, the ability to do complex, global transaction replication, while also continuing to manage costs.