Amazon DynamoDB vs Redis

• Amazon DynamoDB excels at quite, intuitive object retrievals. The usage of hash and range keys to retrieve flat objects means it's easy to understand what you are going to get and how to map out objects into entities in your data access layer.
• Amazon DynamoDB is great at adding new indexes to a table, making it fast and intuitive for prototyping.
• The ability to use Amazon CloudWatch monitoring on Amazon DynamoDB is very helpful for managing data analysis and discovering issues without a large investment.

Read full review

• Redis is easy to learn and concepts are very simple. It's an in-memory storage with regular snapshots for data resiliency.
• Redis offers the possibility to act as a cache with limited but strong eviction set policies. LRU is the most common one.
• The pub/sub feature of Redis is an interesting alternative for efficient and fast data distribution when we don't need a central broker such as JMS. Obviously, it requires some analysis before choosing between the bunch of providers (JMS, Kafka, MQTT, AMQP, Redis, etc)

Read full review

• Because of the lack of relations in AmazonDynamoDB, mapping very complex objects that you would typically decompose into related entities is difficult. Amazon DynamoDB is typically not great for this use case.
• Amazon DynamoDB doesn't do strong type checking (there is typing, but it's relatively limited), so depending on your language you may have to expend some effort to properly map an Amazon DynamoDB object to a programmatical entity.
• Depending on how much need you have for Amazon DynamoDB's performance, it can be a major pain to maintain... especially if you also have a relational database. In my current project, we utilize Amazon DynamoDB alongside PostgreSQL and entities live in one, the other, or both as appropriate. Synchronizing the database is a pain point.

Read full review

• Failover Replicas
• Data Consistency

Read full review

• We were able to achieve our goal using Amazon – store every single email our system that has ever been sent in fluid database for long term recover without significantly impacting query times at scale.
• We have been unable to effectively add additional features using the data set because of the pricing structure and incurred cost involved with performing repeated scans over the dataset.

Read full review

• It was worth it. Got the job done fast and accurately.
• No complaints whatsoever. I don't plan to explore other alternatives anytime soon.

Read full review