DynamoDB is *the* Non-Relational database for the Serverless age
February 23, 2019
DynamoDB is *the* Non-Relational database for the Serverless age
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.
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.
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.