It is useful use-case by use-case. For our use case, it was the best and easiest option for the integration as well as development side. It is serverless so no need of deployment and maintenance hustle. It is easy to scale up due to the same functionality. Supports AWS Security features and just a click away for enabling it so security is good.
Riak is very good if you need a resilient data store that can handle large amounts of documents very fast. If you have 1,000,000 documents and need to execute complex queries, it is great. Riak's SOLR engine is fast, however if you have extremely high amount of queries in a very limited time range, it can fail in a bad way.
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.
Riak works great for our use case but the fact that deletes seem to resurrect is a real issue for us. Unless we can get this solved, we'll continue to look at other products to see if our use case fits. Otherwise Riak is a great product and it fits our use case 95%. We have found work arounds to the remaining 5%.
Functionally, DynamoDB has the features needed to use it. The interface is not as easy to use, which impacts its usability. Being familiar with AWS in general is helpful in understanding the interface, however it would be better if the interface more closely aligned with traditional tools for managing datastores.
While the actual performance of DynamoDB can vary based on workload and region, it is generally highly responsive and well-regarded for delivering low-latency access to data, making it a strong choice for applications with stringent performance requirements. Organizations often choose DynamoDB for its ability to provide a reliable and performant database service, particularly when combined with effective application design and optimization.
Despite Basho going bankrupt and the project becoming fully open-source, community support is reasonably good, albeit a little slow at times. Paid enterprise-grade support is also available from former Basho engineers but the same company also contributes to the community support for free for basic questions or specific knowledge areas.
For our use case, we needed a noSQL that would work with AWS Lambdas of specific parts of the internal web applications. We optimized billing and uses , diversified databases for various parts; so it’s not very expensive.
MongoDB seems to have copied a lot of functionality from Riak. This may be because MongoDB hired a number of former Basho engineers when Basho went bankrupt. That said, the new functions added to Riak after it became open source have successfully differentiated itself from MongoDB.
Amazon S3 is a nice tool but when you are at significant scale with regionally specific data (joys of GDPR), it's much easier to keep it in house and Riak CS lets you do exactly that. All you need to do is point your application at Riak CS instead of Amazon S3 and it just works as if nothing has changed.
When we evaluated against Cassandra, we found the tools available did not match our needs at the time.
I have taken one point away due to its size limits. In case the application requires queries, it becomes really complicated to read and write data. When it comes to extremely large data sets such as the case in my company, a third-party logistics company, where huge amount of data is generated on a daily basis, even though the scalability is good, it becomes difficult to manage all the data due to limits.
Businesses may only pay for the services they actually use thanks to DynamoDB's usage-based pricing approach.
AWS handles hardware provisioning, data recovery, fault tolerance, patching, and database upgrades for DynamoDB since it is a fully managed database service.
DynamoDB differs from conventional relational databases in terms of its data model, which might be difficult for developers accustomed to dealing with SQL-based systems.