Amazon DynamoDB Reviews

The first use case was indexing large quantities of data streaming in from Kinesis so that we could look up the data and collect it for MapReduce jobs.

Its current use case is as primary storage for a web-based service. It's a global data store for everything to do with content and customers.

In terms of its version, it's hosted. There is no version. You just have DynamoDB.

We switched to DynamoDB from a relational database that would've had scale problems and would've cost a lot of money to run at scale. DynamoDB allows us to match expenses to usage. When not many people are using and it's a quiet day, there is a low cost. On a busy day, there is a higher cost. We get good performance along the way and less maintenance on the database.

Something they refer to as wide tables are valuable. Another one is transaction-based pricing.

It has a stable millisecond response time irrespective of how big the database is, and it also integrates with other Amazon services.

I'd like to see better integration with Cognito. It has the integration, but I'd like to see a little more ease of setup. If you have multiple customers and you want the database to enforce who can see what, you can treat DynamoDB so that each row has permissions. You can set this up, but it's a little more of a science project to make Cognito and DynamoDB work well to do protection of individual rows. So I'd like that to be more wizard or easy to set up.

Documentation and examples can always get better.

I have been using this solution for about eight years. 

It's extremely stable.

It's scalable. It's customer-facing. So, there are tens to hundreds of thousands of users, and the usage is growing.

Amazon is pretty responsive. You sometimes have to be very clear in your question if you want a clear answer quickly. I'd rate them a four out of five. 

At this company, I was using MySQL.

It's pretty simple. It doesn't require any special deployment, and maintenance is mostly configuration. It's cloud-based. So, you're not watching the servers. One good DevOps person is enough to handle DynamoDB and everything else on Amazon, and even that's not full-time yet.

There are no separate license costs. You can get committed capacity or transaction-based pricing.

If you're doing it on demand, they charge based on whether you're reading or writing. They charge $1.25 for every million rights to the database and 25 cents for every million reads from the database. The first 25 gigabytes of storage are free, and they charge 25 cents a gigabyte a month. So, it's a very different world. It's a quarter a gigabyte a month. You can store a lot of data.

They have a separate fee for automated backup, and if you want it globally distributed, where it's distributed around the world, there's a slightly different price. It's like utility billing. They charge you based on usage. 

I would rate it a five out of five in terms of pricing. It's a very effective solution.

I didn't evaluate other options at this company. I've used DynamoDB before. So, I know what it's good for and what it's not good for.

My advice to those implementing DynamoDB would be to forget everything you know about database normalization. That's what I would recommend because if you are a real expert with relational databases, it's going to be a bit of a mind warp to use DynamoDB. It would be the same mind warp as if you were using Mongo or any other document or non-relational database. You just have to try not to force it to act like SQL. Treat it like it should be treated.

It's definitely a 10 out of 10.

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.

We use Amazon DynamoDB to manage our localization data.

There aren't any issues with the product. On the contrary, it has helped us build our product from zero point to the end. In addition, I like that there's no need for external configurations or DevOps engineers.

The documentation is not good enough and can be improved. There is a lot of information, and it is old and hard to find specific information. The documentation should be updated like the Firebase in Google.

It is not easy to manage. For example, uploading a certificate and resources to our GraphQL databases is too difficult because there's no user interface. You need to jump into terminal business.

We have been using this solution for two years.

We have not used technical support before.

I just used Neo4j, which is an Amazon AWS product. Unfortunately, the price is increasing daily, and it is tricky to implement things inside AWS. It's not easy, but it's doable.

The initial setup is complex, and you need to search Google to find the correct information. I rate the initial setup a four out of ten.

We used a credit from AWS for this solution. I don't remember specific details about the cost, but it is costly. I rate the price a two out of ten. I live in Turkey, and because of the currency, it is high. I think Amazon needs to create a cluster or environment in this geographic territory so we can spend in our currency and not dollars.

I rate this solution a seven out of ten. Amazon DyanamoDB has its triggers, and we would like them to simplify the process of adding a trigger without taking care of the API code. Once something has changed inside of it, it triggers a function. You can bind Lambda Function, but it's tricky because their containers are working. So, you need to know every detail about Amazon containers. So, Amazon DynamoDB creates a default and runs the function for us. So the only thing that I would be responsible for is adding our code.

My company has a fleet management system, and we primarily use DynamoDB to store location data.

I appreciate the visibility of DynamoDB, as I can observe everything on the Console. I can also monitor its operation with CloudWatch. As more data comes in, although we pay more, the product scales well. However, it can be expensive.

There is nothing that I can think of for improvements.

I have been using DynamoDB for five to six years.

Amazon DynamoDB is pretty stable. I haven't encountered breakdowns or bugs.

DynamoDB scales well. As more data comes in, it becomes more expensive, however, the scalability aspect is not a concern.

About 30% of the time, Amazon's support lacked enough knowledge to solve my problems. 

Neutral

The initial setup is straightforward.

As more data comes in, it can become expensive, however, it's a manageable cost.

I would absolutely recommend DynamoDB to others. It's easy to use, especially if sticking with AWS. 

Overall, I would rate DynamoDB nine out of ten.

We mostly use it for e-commerce data.

Any inflow of new data, whether it is new input or schema inflow, can be captured and stored in DynamoDB. Any variables or inputs can be captured in DynamoDB.

It's easier to scale than other databases.

It's serverless, scalable, and we can replicate and do blow letters. It's okay from my side.

When creating login credentials, we can make a security setup while using DynamoDB.

It has a different schema type than other databases. DynamoDB has a separate schema.

It is a schema-less, NoSQL database. When connecting to other services, we need to sort and code the data. We need to especially monitor the coding of the data. There will be some minor changes to normal coding.

I have been using it for two years. 

I would rate the stability a seven out of ten. We faced some configuration issues.

We mainly need to know the configurations and settings. They need to be customized before setup can be done.

We are a small company; only four developers use it.

I would rate the scalability an eight out of ten. 

AWS technical support is very friendly and looks out for the business to continue. They will support you based on your support ticket.

Positive

I have used Azure. It was for a previous project.

For deployment, we use libraries. If you want to create a library, it's basic functionality. We can call it by integrating with any Python library. We can deploy it very quickly and easily.

Compared to MongoDB, we can set up DynamoDB within half a day.

AWS handles the maintenance.

It's pay-as-you-go. You pay for how much you use and store. We can also make automatic backups and use replication for the database. It is suitable for high-performance applications.

It's on a monthly basis. So it's a subscription.

We use it for support services, so we subscribe to it only when needed. So, the pricing can vary. 

I would rate the pricing an eight out of ten. 

I can recommend AWS, especially for enterprise and retail-level customers. 

Overall, I would rate it a seven out of ten. 

I have set up Amazon DynamoDB and started using it with my product for data insertion, creation, reading, testing, and configuration.

Amazon DynamoDB is a NoSQL database that stores unstructured data and provides high performance.

I initially faced issues with the solution's stability, performance, and security.

I have used Amazon DynamoDB two to three times.

I rate the solution’s stability a seven to eight out of ten.

I rate the solution an eight out of ten for scalability.

The solution’s technical support is good.

The initial setup of the solution is average, and it is neither easy nor difficult. You do need to have some knowledge and experience to set up Amazon DynamoDB.

Given the services and benefits provided by AWS, the solution's pricing is average.

Overall, I rate the solution an eight 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.