DynamoDB is *the* Non-Relational database for the Serverless age
February 23, 2019

DynamoDB is *the* Non-Relational database for the Serverless age

Chris Moyer | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User

Overall Satisfaction with Amazon DynamoDB

We've been using Amazon DynamoDB since it was released in 2012. Previously, we used Amazon SimpleDB, which was much slower and slightly more difficult to work with than DynamoDB. DynamoDB is our "Source of Truth" for all data stored within my company, and is used to store all of our administrative information (such as connection details, FTP account information, and contact information), as well as the blog posts that we receive and process.
We have Lambda functions that write information to DynamoDB, which triggers other lambda functions to index that data in both SQL databases as well as Algolia for advanced searching and facet support.
DynamoDB helps us support the very random access patterns that we receive for content. Some days we process almost no stories, while other days we process hundreds of thousands of stories. With DynamoDB, we can automatically scale to whatever needs the day might have.
  • Automatic Scaling (especially with the new on-demand capacity mode).
  • Simple querying of massively large databases.
  • Effortlessly store a relatively unlimited amount of information.
  • Very cost effective for random access patterns.
  • Complex searching (no support for case-insensitive or full-text search).
  • Only supports up to two-key indexes.
  • Requires choosing the indexes up-front when doing searches.
  • Does not have an SQL compatible query front-end.
  • No join-table support (requires putting all data into one table).
  • It's cheaper for us than running SQL databases.
  • We never need to worry about our core pipeline or backups. DynamoDB is highly reliable and always available.
  • We have some issues with complex queries, and gathering statistics.
We used SimpleDB in the past (before DynamoDB existed), but there were several limitations around object size and total size for a given table that we were not able to overcome. DynamoDB has almost no limits, and can scale to store as much data as we need it to.
Similarly, Aurora or any other MySQL DB can only store so much information before it needs to be scaled out further and shared across multiple servers. DynamoDB is completely serverless, and automatically handles sharding for us. MongoDB has more features, but required us to manually manage servers, and was ultimately much more expensive and less reliable for features we didn't really need.
Algolia is actually something we use in addition to DynamoDB, but it's not our source of truth. Since Algolia has limits on how much data can be stored (and you pay more for more data storage), we only store a minimal amount of information in Algolia, what we would search on, and the sources of truth are always in DynamoDB. Additionally, Algolia's search performance is limited, so we only use it for searching unknown or unexpected use cases, such as listing how many publications or stories match a particular query, vs DynamoDB which is used to look up when a user logs in.

It's core to our business, we couldn't survive without it. We use it to drive everything from FTP logins to processing stories and delivering them to clients. It's reliable and easy to query from all of our pipeline services.
Integration with things like AWS Lambda makes it easy to trigger events and run code whenever something changes in the database.
Amazon DynamoDB is absolutely the easiest and most efficient way to run a Non-Relational database. It's perfectly suited for a "source of truth" where other indexes might be built from data stored in DynamoDB, and for use where search patterns are predictable. It's also incredibly effective at storing relatively unstructured data, or data models that might frequently change. As it does not require a rigid definition of data beforehand, it makes adjusting data stored in the table a non-effort, but it does require some planning when looking at how to get data back out of the table.
Unlike traditional SQL or Relational databases, DynamoDB is designed to have all relevant information within a single object. If not properly planned, this can lead to issues when building out a front-end. DynamoDB does not have join table support, nor does it support complex searches or "count" style responses. It is eventually consistent, although they recently did introduce Transaction support, there is no "rollback" option.

Amazon DynamoDB Feature Ratings

Data model flexibility
Deployment model flexibility