Amazon DynamoDB Reviews

We are using Amazon DynamoDB to store structured data. We recently created an application that stores streaming data from different events in DynamoDB for further processing and analytics.

Using DynamoDB allows us to handle large amounts of data without worrying about scalability, failover, and other concerns. It has been beneficial for us compared to MongoDB, where we had to handle everything ourselves.

The most valuable feature of DynamoDB is that it handles a large amount of data efficiently. Being serverless, it alleviates concerns about scalability and failover. The integration with other AWS services is also very easy.

I don't have in-depth knowledge to suggest specific improvements for DynamoDB, however, I haven't faced any significant challenges so far.

We have been using it recently for one of our serverless applications.

I haven't encountered issues with the stability of DynamoDB. Everything was smooth for us.

No worries about scalability since DynamoDB as a serverless service handles scaling well.

If you purchase the support plan, their support team is good. If not, it takes two to three days to respond, sometimes even more.

Neutral

We used MongoDB previously. We switched to DynamoDB since it reduced the need for us to handle everything.

I would definitely recommend DynamoDB to anyone looking to use NoSQL databases.

I'd rate the solution nine out of ten.

One of our customers has been using DynamoDB for four years. They are using it to store long strings of data, particularly experiences shared by people in nature domains, such as recreation zones. 

These experiences could be related to hiking, swimming, observing nature, or anything else. People can send in short messages, and those messages are stored in DynamoDB.

DynamoDB is a service by Amazon. It is what it is. 

DynamoDB is a key-value database, and it's valuable if you have simple scan queries and don't need to do point searches. For example, if you want to see what happened on Wednesday afternoon at two o'clock and correlate that with what happened on Thursday morning at eleven o'clock, DynamoDB can handle those queries. 

However, if you need to do more complex queries that involve multiple indexes or multiple keys, you're better off using an operational database. DynamoDB can still be a good choice for single-T value streams and smaller datasets, but it does have a limitation of four KB for a record, which can be restrictive.

Essentially, for those with some experience in the field, we could call it an index sequential access method. 

Maybe the documentation could be improved a bit. Sometimes, it's a little confusing, and people can easily be mistaken about DynamoDB. 

That's the main thing, the documentation could be a little more explicit or a little more elaborate. But that's it. It's a key-value system, and it works well for what it is. The only thing I can see that could be improved is the documentation.

We have been using it since 2019, so for four years now.

The service itself is stable. We haven't found any faults in DynamoDB. It is what it is. I would have developed it or designed it with some more resilience in terms of flexibility and data, but the thing is stable. I've never had a crash.

It is scalable up to its limits. DynamoDB can be used by all types of businesses, from small startups to large enterprises.

We've always gotten help when we've called, so in my case, customer service and support are good.

We don't have any complaints about that or any information to provide on that. We always get a response within the contractual parameters, so everything has been okay for us.

Positive

We have a few DynamoDBs, and we are also planning to restore unstructured data next week.

In 1982, which is now 40 years ago, we were working with an IBM system called ISAM and VTAM. Those very old mainframe systems were exactly what DynamoDB is today.

DynamoDB is a key-value storage device for a system. You have a key, which is one, two, three, and you have values, such as apples, orange juice, pears, whatever. 

You can have a data construction or design in which you have one value with one key, or you could have a data structure designed for your application with a specific type of data. And then, you have to set up your DynamoDB accordingly. So, again, it's like comparing what is better: white bread, whole wheat bread, or slightly less white bread. It's all still bread.

Any service in AWS is relatively easy to deploy. The deployment time for any variable GB is about a second.

One person can do the deployment. The service itself doesn't require maintenance. It's the content that needs attention. It's like any data store or any form. If you put garbage or corrupt data in it, you will get a corrupted result. So, the service itself is flawless. It works exactly as advertised. 

But if you store the wrong data in it, with the wrong key and the wrong values, you will get the wrong results. So, the maintenance is not so much in DynamoDB itself. The maintenance is in your data stream.

We have a cloud engineer who takes care of running, upgrading, and supporting about 60 to 70 DynamoDBs in the physical sense, although that might be a bad term to use with cloud services. And he does it all by himself. So, one person can, in the current state of affairs with cloud services, oversee quite a large number of services.

Compared to a high-end relational database, it's cheap. But then it doesn't have the capabilities of a high-end relational database because it's not meant to be a high-end relational database.

So, it's like looking at what the price difference is between a scooter and a Bentley or a GTR. They are means of transport that are in a different league altogether. So, you don't compare a Bentley with a scooter.

The pricing is based on usage. DynamoDB is one of the services within Amazon Web Services. So, the pricing for anything in cloud services is based on usage and volume. So, the more you use it and the more volume you pump into it, the more the price will go up. But that is the normal business case for any storage service in the cloud.

If you've done your data architecture and analyzed what you'll be using your data for, where you'll be using it, and you have your data flows and conceptual model, and you see that it's a sequential storage of keys with values attached to it, DynamoDB is a valuable and valid option. 

However, don't use it just because it's easy. You should use it when you don't need some of the other aspects of a relational database, like joining, multiple endpoints, and comparing or having a key on multiple datasets. If that's your use case, if you want it for your entire application, don't use DynamoDB. 

But if it's for something simple, like a record of sales or events happening on a particular day or moment, please do use DynamoDB. It all comes down to the quality of your data architect.

I would give it a ten in some cases and a zero in others. For example, if you want to have a research database where you need multiple perspectives on the same set of data, and you try to do that within DynamoDB, you're going to have trouble.

But if you have a log and you want to do some statistical research on, for example, the sales in a supermarket, which are a simple timeline with the cash register data, timestamp, value, and then the goods, that's all very simple, key-value, and you can use DynamoDB for that.

So, it depends on the use case. For the use cases that you're using it for, you would give it a ten. So, the solution is excellent for the purpose you're using it for.

For my use cases, I would rate it an eight out of ten. We chose DynamoDB. We could have done the same thing with a relational database, but then again, you wouldn't choose a Bentley Continental GTR just to go to the grocery store. You can go to the grocery store on a scooter. 

We decided against the relational database because of the overhead and cost, and we went with DynamoDB instead. Because the dataset is just a key timestamp and some values, a key and a value, we can restore them sequentially, which is exactly what DynamoDB can do without any problems.

Personally, I use DynamoDB for creating my Proof of Concepts (POCs) for testing DynamoDB functionalities. It's not used extensively by me but is likely used by the database team.

DynamoDB is easy to configure, easy to use, and allows for writing data in JSON format.

I have not used it extensively at a larger scale, so I cannot provide feedback on improvements.

I have been using DynamoDB for about four years.

I haven't used DynamoDB in large volume, so I haven't faced any stability issues during my usage.

I haven't used DynamoDB for large scale data handling. I've used other solutions like MongoDB and S3 for such purposes.

Support is better if using a paid version. I gave the support a rating of seven out of ten.

Neutral

I have used other resources like MongoDB and S3 for handling large-scale data.

I would recommend DynamoDB to other people.

I'd rate the solution eight out of ten.

We use the product as our database. It is a NoSQL database. We can use DynamoDB as our database if we don't need SQL.

The best feature of the solution is that it is a NoSQL database. Many tables make a database. When we define a table, we have to define the schema of the table. For NoSQL databases, we don't need to define it. The table accepts any input. Each row will have its own column. We do not have to define the columns in advance. We can add columns to each row and push the data. We can query as much as we want.

SQL databases exist to speed up the queries. This advantage is not present in NoSQL databases. We must query databases very fast. To help with the process, the product provides secondary indexes. Secondary indexes are a copy of the table. The table is constructed in such a way that it can be used to support one query. Whenever we query a particular item, if we give the name of the secondary index in the query, the query will be faster.

The solution supports around 20 global secondary indexes. We can just create a table without thinking about its format. When our application develops, we will have more and more queries to do. We might realize later that the initial table does not support the query and that we have to change the schema of the table. To do so, we will have to change the structure of the entire table for one query. In DynamoDB, when we encounter a new query, we can just create a new secondary index for that to an existing table. We wouldn’t have to modify the main table. The query will be fast when we query the secondary index, which is a copy of the main table. Through the production process, we don't have to be concerned about modifying the main table.

The product allows us to query for items in the UI. Sometimes when we query through the UI, it takes a long time to get the results. I would like it if the results were faster.

My organization has been using the solution for more than one year.

The product is stable. We have had no issues. We always get the data.

The solution is scalable. Around four people were using the product before. Now, only two people use it in the organization.

We were using MongoDB. It was outside AWS, and we wanted to get everything inside AWS. So we chose DynamoDB. I prefer DynamoDB over MongoDB.

The solution is deployed on the cloud. The initial setup is very easy.

If we go through the main DynamoDB, it will be a scan operation. It will scan through each record. If we set up a secondary index for a particular query type, we can get it fast. It is the fastest way to get it.

In a normal database, if we launch something into production and want to add one more feature, but the feature needs an additional query, and the existing table cannot perform the query fast, we will have to remodel the entire table. It will interrupt the process. In DynamoDB, we can just add one more secondary index and route that query to the secondary index.

If someone wants to use the solution, they should go ahead. It is as good as anything else. Overall, I rate the product a nine out of ten.

I use Amazon DynamoDB for EMR automation for EMR to run. Right? We have to configure everything on time since we have configurations on Amazon DynamoDB.

We mainly use Amazon DynamoDB, like a session DB kind of solution. Also, the solution's pricing is really nice. So I use it because I don't have to pay for it throughout. It is based on the usage that I have to pay. So that is where MySQL, I had to pay 24/7. With Amazon DynamoDB, I had to pay only when I used it and the amount of data I had stored. So, it reduced my cost since it was much cheaper as compared to MySQL.

The solution's interface is the biggest challenge because if you want to access DynamoDB, you need an AWS account. So, you need to be logged in to the AWS console and can only make changes from there. So, if there's, like, any other DB, like, whether it's Redshift or any other service that shows us Spectrum, Athena, or anything they provide, we can connect it through an external client. I don't need to be logged in to the AWS console. That is one thing where it restricts me, and as of today, I've restricted its access to four people who can make the changes in the product or who can monitor or directly log in to DynamoDB and check what has been configured, what is working, what is not working. But if it was accessible, like any other DB, I could have just given them more people to read permission, and It would have been easier for me to maintain that.

As of now, I'm using it as a configuration DB and not exactly using it for transactions or storage since, for such purposes, I depend on Redshift.

I have been using Amazon DynamoDB for a year and a half.

Stability-wise, I rate the solution a ten out of ten. I've never faced any problems.

Scalability-wise, I rate the solution an eight out of ten. Ideally, it is supposed to be instantaneous after we make a request, but it wasn't since I had to, like, it took me some time to increase the size of Amazon DynamoDB. However, the opinions from my other colleagues and ex-colleagues indicate that it is faster. Based on my experience, I haven't had a similar experience as my colleagues.

I don't have direct users on Amazon DynamoDB. It's applications that are accessing it now. I don't even have multiple applications such as workflow and big data. I have probably a hundred-plus workflows that are running on a daily basis.

I have never had any issues with AWS support since they have been fast and helpful, and I have them on my speed dial. So, I can just call them and reach out to them.

Previously, I was using Cloudera platform, where we were using MySQL as a configuration repository because we have been building big data pipelines and other things. So, what happens is that queries and other things that we have to fire on Redshift DB or maybe in Hudi or Kudu, all these DBs that are part of the Cloudera stack, we used to store all the queries in MySQL. We then decided to move out of Cloudera and go to EMR. For us, the easiest option was to go for MySQL, but it is not that closely integrated with AWS EMR. So it would have been an outside product being introduced or coming into our environment. Hence, we decided to go with DynamoDB, as it is an AWS product.

The solution's initial setup was simple.

I got myself involved in the process.

On a scale of one to ten, where one is a high price and ten is a low price, I rate the pricing a seven. It is not the cheapest, but it is not the costliest either.

I don't think I will be able to compare DynamoDB with other solutions in the market since there's a huge difference between any other DB that I have used and DynamoDB. I will not be in a position to give an objective view.

Overall, I rate the solution an eight out of ten.

The solution is being used for scaling. For instance, if your throughput is X, then automatically, we can handle two X without incurring any additional cost, which gives you leverage over the spiking nature of the customer.

The latency feature is precious.

The setup cost could be reduced. But overall, the tool works smoothly.

I have been using Amazon DynamoDB for the last two years. 

Amazon DynamoDB is a managed database by AWS, so it handles scalability. I've seen improvements in scalability. For customer data, they replicate it three times independently of use, ensuring they can handle peak throughput at twice the usual rate. From a cost perspective, I'm charged based on the amount of data scanned and returned.

It provides premium support for enterprise solutions and real-time assistance.

Positive

Integration with Amazon DynamoDB is straightforward due to clear documentation and comprehensive support. 

Investing in Amazon DynamoDB has provided us with reliability and scalability, which are crucial for our operations. This has been a significant return on our investment.

It is costly. To reduce the costs, users need to read the node in front of it. For read-heavy groups, cache optimization can help manage costs. I can't disclose specific pricing, but it's competitive compared to others in the market, and this information is easily accessible online.

Amazon DynamoDB stands out primarily in its managed database feature compared to other tools. While other tools like MongoDB offer similar support, DynamoDB excels in its GSI and LSI capabilities, especially in partitioning and data handling. Its reliability and security features are notable, meeting our company's data security requirements.

I would rate Amazon DynamoDB an eight out of ten, primarily for its reliability, scalability, and security features. In terms of support, I would rate it above nine, especially for enterprise solutions with premium backing that ensures real-time assistance.

DynamoDB doesn't directly support AI-driven applications, but it can certainly be used as a backend database for such applications.

I would rate Amazon DynamoDB an eight out of ten, primarily for its reliability, scalability, and security features.

DynamoDB is suitable for a wide range of applications, from small-scale projects to large-scale and high-traffic applications. Amazon DynamoDB is a high-performance managed service, and AWS fully takes care of the operational parts, including hardware, setup, and maintenance.

Amazon DynamoDB is a fully managed service by AWS, and it is designed to provide fast and predictable performance.

The solution's backup and restore could be improved to be able to utilize batch operations.

I have been using Amazon DynamoDB for more than two years.

Amazon DynamoDB is a stable solution.

Amazon DynamoDB is a scalable solution. More than three people are using the solution in our organization.

The solution’s technical support is good.

The solution’s initial setup is easy.

Amazon DynamoDB is a cheap solution.

Amazon DynamoDB automatically publishes AWS CloudWatch metrics that provide information on health and performance, read-write capacity, system errors, and conditional check fail requests. It is easy for somebody to learn to use Amazon DynamoDB. I would recommend the solution to other users.

Overall, I rate the solution ten out of ten.

We have enabled a state-locking mechanism in Terraform, so we store our keys in DynamoDB. 

If the database is kept running continuously, extra costs will be incurred. This particular area needs enhancement.

I rate the platform's stability a nine out of ten.

I rate the platform's scalability a nine out of ten.

The technical support team is always available to help us.

Positive

I worked with MongoDB and Firebase earlier. I switched to DynamoDB because of the company and client requirements. Atlassian and Google already own the other two services. I used MongoDB for a machine learning project and Firebase for an Android-level project.

The initial setup process is easy.

I have yet to use DynamoDB for real-time data processing in my applications. However, in Terraform, we utilized it to create multiple infrastructures. Terraform has a state-locking feature, which prevents simultaneous data updates from multiple users. For example, triggering a data update one minute before you do will lock your access until my update is completed. We implemented this feature for telco data monitoring purposes.

Data modeling in DynamoDB is simple and easy to use in our cases. You have primary and secondary tables, and then you can easily model the data. Whatever you use to access the non-structural data is how you get the storage, i.e., API gateways, workflows, and microservices that need to communicate with each other. This is where the database comes into the picture.

I advise others to be thoughtful and careful when using the platform because if you keep the database running continuously, it might cost you a lot of money. 

I recommend Amazon DynamoDB to others and rate it a nine out of ten.