Amazon DynamoDB Reviews

I integrate Amazon Connect with Amazon DynamoDB for the database.

Amazon DynamoDB is serverless and fast, and we can use different keys along with it in our code. Amazon DynamoDB can accommodate any number of datasets. It is better than the RDB (relational databases). We can use the primary and sort keys to get any sorted data, which is good. The solution is easy to use.

Anyone with AWS Lambda knowledge can easily integrate and use Amazon DynamoDB. The solution supports all languages.

The solution would work fast if a contact center is in the same region.

I have been using Amazon DynamoDB for four years.

We haven’t faced any issues with the solution’s stability.

We can scale Amazon DynamoDB as much as we can.

I rate the solution’s scalability a nine out of ten.

We can integrate Amazon DynamoDB with other AWS services in our architecture with a simple function. I would recommend the solution to other users.

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

The solution makes it simple to manage the database.

The most valuable features of the solution are its price and stability. The solution can handle all our payloads and workloads. The solution's documentation is very clear. Amazon DynamoDB is a good solution that is easy to configure. Data security is one of the main reasons we use the solution.

The solution's initial setup is a bit complex if you want it for something more specific.

Amazon DynamoDB is a stable solution, and I haven't faced any issues with stability.

More than 1,000 users are using the solution in our organization.

I've used MongoDB. I like both Amazon DynamoDB and MongoDB because they take different approaches. However, if I have to recommend one over the other, I will recommend Amazon DynamoDB.

The solution's initial setup is a bit complex if you want it for something more specific. However, it can be straightforward if you need it for something basic.

The solution's pricing is good, and it's not expensive.

The solution has helped us save 30% of our costs. Our main project is automation to help businesses communicate with their clients.

Overall, I rate the solution a nine out of ten.

It is a NoSQL product. We can write what we want, and it will be stored. We need not worry about the structure. If we want to use a database for small use cases, we can use DynamoDB. If the CPU is high in a day, I can check what time it went high, how many people came into the site, and understand the database usage. Whenever the CPU is high, I send all the data to my database and analyze why it is high so that I can minimize the usage accordingly.

If we want to add another field, we can do so easily. It won’t show any errors. There is no need to migrate. Data modeling is easy. Whatever language we use with the product, we must check how to connect and write it. We must use some DynamoDB functions. I use the product with Lambda.

The pricing for larger databases is higher.

I have been using the solution for one and a half years.

We did not have any issues with the tool’s stability. We did not face any issues with bugs.

The tool’s scalability is good. I rate the scalability a nine out of ten.

The initial setup is straightforward.

We mostly use PostgreSQL.

I have used Amazon RDS. We do not use DynamoDB much. I will recommend the product to others. If we want a small database, Amazon DynamoDB is a good choice. We can use it for larger use cases, too. However, pricing might be high if we opt for the larger database. Overall, I rate the tool a nine out of ten.

Amazon DynamoDB is powerful and fast. Its performance is good. 

The solution has size limitations. It also needs to be more user-friendly. 

I have been working with the solution for one and a half years. 

I would rate the product's stability a seven out of ten. 

I would rate Amazon DynamoDB's scalability a nine out of ten. We have 100-200 users for the solution. 

Amazon DynamoDB's installation is not complex. 

Amazon DynamoDB is cheap. 

I would rate the solution a seven out of ten. 

We use Amazon DynamoDB to store data. We have a hardware device that is continuously reading data. For example, there is a sensor generating weather data every second, and we collect the data after 30 seconds. So, the data is quite huge. We store this data in DynamoDB.

Depending on the client, we show some charts, etc. as well.

Storing is a valuable feature. We can store data as an entire object rather than the traditional structure of the data.

Accessing speed is very fast. We have never faced any problems accessing the data.

It is stable, scalable, and easy to install.

There are some issues, like if we missed something or somehow were not able to store the data, then it was quite difficult for us to get back that data.

If some data crashed during transmission, then there were no alternate options to recover that packet, to backup, or to re-collect that data for a specific device.

Caching is a problem; it is not there. In DynamoDB, my experience is that it works like a UDP; whatever is lost is gone. There is no other mechanism by which we can re-collect that data.

I would like to see video and audio buffers in DynamoDB. 

I used it for around just three months.

It is a stable solution, in my experience.

We currently have 1000 devices.

Every hour, out of 100 devices, around five devices were missing some data packets. It was not very constant as in similar devices but was at random. On average, five devices were missing data every hour.

The DevOps team was raising the tickets with technical support, but we didn't have any problems with the Amazon side.

The initial setup was very straightforward. Deployment and configuration took about a week.

If it is a real-time system, very specific to the domain, it is a great solution. If it is embedded, has huge data, the frequency is quite high to store that data, and the device is in a remote area or there is no connectivity, then this solution is perfect.

However, if the device is connected through the internet, then it's definitely not a good solution. That is, if it is connected to the internet and proper connections are there, then this solution will not be not feasible.

If I were to rate this solution, I would rate it at six on a scale from one to ten.

I am currently using it for proof of concept and testing out its capabilities. We are publishing the IoT data on DynamoDB. We have its latest version.

Its scalability is really good. I can go up to a petabyte of data. It is more of an on-demand use case. I can go from 100 MB to 1 PB if I want, which is very good. Most of the other databases would want you to stick to a specific data allocation. 

Its subscription cost is lower than similar databases offered by other vendors.

Currently, there is no option for a scheduled refresh in this solution. We want the data to be populated into DynamoDB on a timely basis. Currently, you have to go to the DynamoDB table and hit the refresh button to populate it with the new data. If you have connected DynamoDB to a BI application for creating visualizations with charts, graphs, or other things, you would want it to get updated as per the schedule so that you have updated visualizations in your BI application.

We have been using AWS for close to one and a half years, and we have been using DynamoDB for 45 to 60 days.

It is stable. It is meeting our requirements. In fact, it is way better than what I expected. It is doing more than what I need.

Its scalability is really good. I can go as low as 100 MB and as high as 1 PB.

I didn't run into any issues, so I didn't need any support. The forums and documentation that Amazon provides are pretty much self-explanatory.

We were using another service called Amazon RDS for our data requirements. RDS is not as quick as DynamoDB, but it is not meant to be as quick as DynamoDB. RDS has its own use case, so they are not comparable. They have different use cases. We are switching to DynamoDB because our use case changed.

It is pretty straightforward. It is as simple as it can be. You do need to know what sort of data you have, which is a minimum requirement. After you get that in, everything is very much simple. You don't even need to go through a tutorial. It is that fast.

It is being done in-house, but as our client base grows, we might end up switching to a consultant.

Its subscription cost is lower than similar databases offered by other vendors.

I would recommend this solution based on the use case. It is pretty straightforward, and we haven't had any major issues. It is just plug-and-play. There is nothing else that you need to do.

I would rate Amazon DynamoDB an eight out of ten.

We have various use cases for the solution, including using it for IoT, messaging, etc.

The possibility of managing documents is the most valuable aspect of the solution. I like the fact that I don't have to define the fields. 

Features like the user interface and the pricing of the solution are also good.

Querying data on the solution is quite limited, but this is like any other NoSQL database. It's the most common criticism of the NoSQL database in general.

The solution is absolutely stable.

The solution is scalable.

The initial setup was straightforward. The deployment over DynamoDB services is a few seconds.

I implemented the solution myself.

We are using the public cloud deployment model.

I would rate the solution eight out of ten. I'm quite satisfied with the solution. Querying could always be better, but it's a typical complaint.

The design approach of DynamoDB makes it very fast and scalable.

We have used most of the features offered by DynamoDB because the product is mature and they fit very well.

They are planning to introduce versioning in the future (http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html).

The application runs much faster and the query response time is three to five times faster when compared to Google Datastore.

The admin console is also very user friendly and provides hands-on features for the development team.

It provides good support for local development.

• The documentation could be refined to explain some basic topics better.
• The local DynamoDB version doesn't come with a tool to view the items inside the tables, so a third-party licensed product is required.
• An API to make the creation of complex queries with filters, limits, and offsets much easier is something to consider for future releases.
• Some things must be implemented manually and that takes a lot of time. At the same time, they are offered within the API in other NoSQL solutions.
• There is room for improvement of how the indexes are handled.
• An automated tool for increasing and decreasing the read/write capacity based on alarms would be welcomed.

We have been using the product for around six months.

There have been no stability issues. It works very well so far.

The design is based on key-value and offers great scalability and speed.

We have been using paid technical support during the development phase. I would give technical support a rating of 9/10.

They respond very fast and give good solutions, but sometimes they realize that it is a bug in the product and can't tell you when it will be fixed.

We used Google Datastore, but we switched to DynamoDB because we migrated to AWS.

The initial setup was straightforward.

Pricing is more complex than buying a license, so it depends on the products' needs.

We evaluated Microsoft Azure as a cloud solution, but in the end, we decided to go with AWS.

If you want a very fast NoSQL database, and you are willing to do some extra work in order to implement complex queries, DynamoDB is the way to go.