Amazon DynamoDB vs Redis

• 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.

Read full review

• Caching - that's what it's built to do, and it does it well.
• Performance - pretty much everything happens in memory, so it's blazing fast.
• Atomic operations - when you need a distributed counter, Redis is a great option for avoiding race conditions across services/servers.
• Blocking calls - polling for changes kinda stinks, and Redis gives you the option to perform blocking calls that immediately return when data is ready.

Read full review

• 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.

Read full review

• Redis may not be for you if you want to deploy a cluster but don't have at least 5 different devices since it requires at least 3 masters and 2 slaves for the configuration to work.
• The reason redis is really fast is because it resides in your RAM hence it might be a problem when you have an application that needs a lot of RAM and it has to share that with redis. This will depend on the size of your application, users using the applications and obviously the amount of RAM you have.

Read full review

• Better faster coding for data storage and retrieval
• Can get very expensive very fast for some use cases, while really cheap for others
• Hidden errors and short falls leads to very frustrating troubleshooting

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