https://aws.amazon.com/blogs/database/how-to-determine-if-amazon-dynamodb-is-appropriate-for-your-needs-and-then-plan-your-migration/ https://aws.amazon.com/blo

https://aws.amazon.com/blogs/database/how-to-determine-if-amazon-dynamodb-is-appropriate-for-your-needs-and-then-plan-your-migration/ https://aws.amazon.com/blogs/database/how-to-determine-if-am... It is best in extreme cases. Some types of high scale use and super super cheap serverless/bootstrapping startup smaller scale. Low-scale - it is easy to create a table and just start writing to it. The pay per request pricing is simple and plays well with IAM, other AWS services and the serverless framework. High-scale - scales easily up and down, global replication is easy, backups and high availability are easy - it is all self-managed so a lot of this is baked in or very easy to toggle on. Depending on your ops resources, the easy tooling may be worth the extra costs or maybe your data lends it self particularly well to how dynamodb works. Some of our use cases .... - user profiles to supplement cognito user attributes - chat/chat groups/chat group memberships/chat websocket watchers/chat messages (this one was not good. I would do it again with just messages and the websocket watchers) - tenant data with lots of custom attributes - forms and form submissions - event webhooks from 3rd party services - catch/store/process using dynamodb streams - step function states and logs - it has some nice versioning write patterns - web scraping data from ebay - web scraping data from golf tee time sites When you need search or flexible querying you can put elasticsearch in front of it and use dynamodb streams to push items into the index. If you need analytics you can use another layer like redshift.