Amazon’s DynamoDB — 10 years later

To get to 2007, I have to start with 2004, 2005. Even as I was working on my PhD [Sivasubramanian earned his PhD in computer science in 2006 from Vrije Universiteit Amsterdam] I was contemplating where I would work. Ultimately what convinced me to join Amazon as a research engineer intern [2005] was seeing how Amazon was pushing the boundaries of scale.

I admit I was a little bit of a skeptic as an outsider. At that time, AWS didn’t even exist. But when I joined, I soon had an ‘a ha moment’ that, yes, Amazon was an e-commerce company, but actually it was a technology company that also did e-commerce. It was an interesting revelation for me seeing how Amazon had to invent so many new technologies to even support its e-commerce workload.

As an intern, I was working as an engineer on amazon.com and during our peak holiday traffic time we experienced a serious scaling failure due to a database transaction deadlocking issue. The problem was caused by the relational database from a commercial vendor that we were using at the time. A bunch of engineers got together and wrote what we call a COE, a correction of errors document in which we say what happened, what we learned, how we fixed the issue, and how we would avoid a recurrence.

I don't know if it was me being naive or just being confident in the way only a 20 something intern can be, but I asked the question ‘Why are we using a relational database for this? These workloads don't need the SQL level of complexity and transactional guarantees.’

This led us to start rethinking how we architected our underlying data stores altogether. At the time there wasn’t a scalable non-relational database. This is what led us to build the original Dynamo, and which led us to write the paper. Dynamo was not the only thing we were rethinking about our architecture at this time. We realized we also needed a scalable storage system, which led us to build S3, and we also realized that we needed a more managed relational database with the ability to do automated replication, failover, and backups/restore, which led us to build Amazon RDS.

One rule we had related to writing the original Dynamo paper was not to publish when we developed the original design, but first let Dynamo run in production supporting several Amazon.com services, so that the Dynamo paper would be an end-to-end experience paper. Werner and I felt very strongly about this because we didn't want it to be just another academic paper. That’s why I was very proud when 10 years later that paper was awarded a test of time award.

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.

When we started with DynamoDB ten years ago, the cloud itself was something customers were just starting to understand better — its benefits and what they could do.

Now we live in a world where cloud is the new normal in terms of how customers are building IT applications, and scale is also the new normal because every app is being built to handle viral moments. DynamoDB itself will be on this continuous journey where we will continue to innovate on behalf of customers. One of the things we will continue moving toward is an end-to-end data strategy mission because, as I mentioned earlier, no database is an island.

Customers no longer want to just store and query the data in their databases. They then want to analyze that data to create value, whether that’s a better personalization or recommendation engine, or a forecasting system that you can run predictive analytics against using machine learning. Connecting the dots end to end, and continuing to make DynamoDB more secure, more available, more performant, and easier to use will be our never-ending journey.