Impressive when used as designed; otherwise, risky
December 12, 2018
Impressive when used as designed; otherwise, risky
Score 8 out of 10
Vetted Review
Verified User
Overall Satisfaction with Amazon DynamoDB
The engineering and data teams use DynamoDB to persist data for some of our services. We use it as an inexpensive, fully-managed key-value store. The business problem it primarily addresses is developer velocity. With DynamoDB, developers do not need to configure and manage a database; even RDS requires some more configuration and on-going maintenance than DynamoDB. DynamoDB is inexpensive; it allows developers to adhere to practices like one-database-per-service when building even small, temporary services.
- DynamoDB is fully-managed. In the early days, it lacked features like backups, and developers had to either implement some of their own backup functionality or live dangerously. Today, DynamoDB's claim to be fully-managed is more credible. Backups can be configured through the console. Table capacity does not even need to be planned anymore; you can scale (and pay) on-demand.
- DynamoDB is inexpensive for some use-cases. In particular, DynamoDB is very inexpensive when you create a datastore for a low-volume micro-service, or a stateful background job. DynamoDB is much less expensive than RDS or Elasticache for these use-cases, and it allows developers to design systems without worrying about cost.
- DynamoDB is fast when used for the use-cases it was designed for.
- DynamoDB supports the development experience and testing reasonably well. AWS provides an official DynamoDB image that can be used in tests locally or in CI.
- Capacity planning can be difficult, but it is probably a worthwhile exercise in itself. However, today you can scale tables on-demand without capacity planning.
- Migrations can be slow and difficult. If you need to change your schema (e.g., add a secondary index) after you have written a large volume of data to the table or after consumers of the data are live, migrating can be expensive. Tooling for DynamoDB migrations is less mature than tools for migrating other datastores.
- The API is complicated, and third-party wrappers, like PynamoDB, are immature.
- Scanning tables is slow and expensive. It is important to anticipate all of the types of queries you will need to support and design your schema accordingly.
- DynamoDB has increased developer velocity because developers do not need to build and manage datastores.
- DynamoDB can be extremely inexpensive for some use-cases, such as non-critical, low-volume applications that need a simple datastore.
- DynamoDB has allowed us to adhere to design patterns like one-database-per-service that we might have violated if we had to pay for RDS.
DynamoDB is more flexible than key-value stores like Redis-flavored Elasticache. They both offer high-availability. Elasticache requires a little more management, and lacks on-demand scaling and pricing. DynamoDB is not a relational database, but can replace RDS for simple use-cases, like a stateful background job. DynamoDB can be faster and much less expensive for some use-cases. Aurora Serverless is an intriguing option that I have not yet evaluated. I would consider it the time I have a use-case that DynamoDB may suit. Serverless is similarly fully-managed and offers something like on-demand pricing, but provides all the features of MySQL 5.6 and better performance than RDS/MySQL.