Amazon DynamoDB Reviews

There are actually several Amazon services related to Amazon Connect, a contact center solution. These include Amazon Connect, Lambda functions, Amazon DynamoDB, Amazon Kinesis, Amazon SNS, and Amazon SES.

We use DynamoDB to manage our contact center dynamically. This requires the use of a DynamoDB table and Lambda functions.

The ability to store multiple data attributes is crucial. For example, in a contact flow, if a customer calls, we can integrate DynamoDB dynamically. We need only the customer's mobile number as the primary key, which is stored in the DynamoDB table. 

With that unique ID, we can automatically fetch all the associated customer details. This eliminates the need for manual processes or asking the customer for redundant information over and over again like their case ID or past history. DynamoDB allows us to streamline the process.

Another valuable feature is how DynamoDB lets us handle multiple processes within a company. For instance, if customers call with different issues – like inquiries about loans, credit cards, or savings accounts – DynamoDB helps us automatically route each customer to the appropriate department. If a customer has a question about a loan, they'll be seamlessly directed to the loan queue.

There are a few areas of improvement. 

In future releases, I would like a feature that lets us store information about public holidays or weekends. When customers call during those closed periods, we could use DynamoDB to trigger an automatic message. 

It could say something like, "We're currently closed due to a holiday. Please call back during our regular working hours."

So this would eliminate the need for agents to manually inform customers.

With a holiday calendar stored in a DynamoDB table, we could write a Lambda function to check the date. If it's a UK holiday, for example, the system could automatically play the message.

It is a stable product because it is managed by amazon.

Anyone using DynamoDB with our contact center is likely using it dynamically. If they're only using it in a static way, they wouldn't need to create a DynamoDB table.

So, there might be 5,000 end users in my org. 

The customer service and support has been good. We can contact the support team for any AWS service, not just DynamoDB, Lambda functionality, or anything else. If we encounter issues or have technical questions, we can reach out to their contact center support.

The initial setup is easy. 

The process is straightforward. You create a table, define the primary key and secondary key, and set any attributes needed for the contact flow. Additionally, you'll need to write a Lambda function. 

This function will call the DynamoDB table, fetch the data, and provide the response back to the contact flow. Within the contact flow, you use the "Get Item from Input" action to invoke the Lambda function and retrieve the DynamoDB data.

Let me outline the architecture: Amazon Connect contact flow sits between the Lambda function and the DynamoDB table. The contact flow sends a request to the Lambda function, which then queries the DynamoDB table. DynamoDB sends the response back to the Lambda function, which then relays it to the contact flow. These three components work together in an integrated way.

DynamoDB has separate pricing. I'm not sure about the exact costs, as they charge based on Lambda function usage.

So, if a Lambda function is invoked with every call, and we receive 5,000 calls daily, that means 5,000 Lambda invocations. So, Amazon DynamoDB would charge accordingly.

So, AWS has different pricing plans.

I'd suggest starting with a static approach. Once everything is stable, then you can gradually enhance the features by transitioning from static to using DynamoDB. It's best to avoid starting with DynamoDB from the beginning.

It is not easy for a beginner to learn how to use it. It will take some time.

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

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.

DynamoDB is a NoSQL, cloud-based AWS service. It is a database service. It supports structured and unstructured data, providing flexibility similar to SQL and NoSQL databases.

While AWS offers relational database services like RDS for structured data, DynamoDB handles unstructured data efficiently. It's designed for scalability and ease of use, allowing users to store and retrieve data quickly without predefined schemas or table creations. This flexibility extends to integrating software frameworks like LAMP, enabling seamless data sharing across applications.

Amazon DynamoDB is known for its cost efficiency and speed compared to other databases. It offers quick performance and rapid data retrieval, often providing limited data initially but scaling up to fulfill larger demands seamlessly. In terms of speed, it outperforms many other databases. There is no need to install anything. There is no need to manage those AWS databases. Everything is taken care of by this cloud alone, right? Everything is taken care of by the Amazon cloud. We must create a table, store data, configure the storage, and write the code. However, these tasks are managed by AWS. There is no downtime up to 99.9% uptime. Even if there is downtime in one region, it's considered in another, so data synchronization happens later, ensuring no loss for the customer.

We are currently consuming this data and storing it using coding. We are storing data in the database and retrieving those details. Everything is based on the EAP, but we are creating. There is no need to go to the particular TIN, DB, or application DB or search for the ID.

Amazon DynamoDB does not currently offer any import functionality. However, users have requested this feature. For instance, if you have a large dataset stored in Excel and you wish to migrate it to DynamoDB, there is currently no direct import option available through the portal. Nevertheless, this limitation can be overcome using third-party tools such as AMP, which facilitates data importation into DynamoDB. Having an import option, whether through browsing or local file uploads, would significantly improve the efficiency of data migration, enabling users to swiftly transfer large volumes of data into DynamoDB.

I have been using Amazon DynamoDB for 5 years.

The product is stable. Most customers are using it because of its stability. They're getting everything, including automatic scanning. Suppose a large number of customers are using it and data are increasing. In that case, it automatically scales, meaning it can handle those data at scale and provide all the data without delay. There is no latency.

We are satisfied with the customer support for Amazon DynamoDB because we haven't encountered any issues with the data handling. Everything is documented, so if a problem arises, we refer to the documentation. We haven't experienced any limitations or drawbacks with DynamoDB.

The initial setup is easy because they provide everything, including CSV imports, pipeline, and Terraform cloud permissions. You can set it up once, and it will automatically generate everything as if you have a proper DevOps team. With a proper DevOps team, creating these setups becomes easy. You can create tables and store data, which will be handled using Lambda and other tools. However, the setup can be managed entirely by having a DevOps team.

The product has a pay-as-you-go pricing model.

If you're using DynamoDB, you also need to understand Lambda coding. In programming, we handle everything, including creating a DynamoDB table, which only takes a few minutes. Once the data management panel is created, we primarily use Lambda for operations. Lambda requires us to write the code for tasks like storing and managing data. DynamoDB is generally straightforward to work with. For example, I navigate to DynamoDB to create a table and make it. However, you'll need to understand various programming concepts and optimize your code for more complex tasks like working with large datasets.

To create the table and input data manually, we need to be proactive. However, updating and handling such tasks programmatically can be challenging. It becomes necessary when developers need to manipulate data through coding, particularly Node.js, Python, or Java. Managing the structure comprehensively while using DynamoDB can pose difficulties.

You can proceed with that option if you want to store data manually. However, from an application perspective, you would need to hire a developer to perform the necessary actions to expose the data through a gateway for other users. It's essential to consider CAPA for applications and presentations. The relevant teams need to develop these CAPA aspects. DynamoDB comes into play to manage the data. We can seamlessly switch data between the backend and the APM. The frontend OS fetches this data from the APM to display in the UI, allowing users to access all the necessary information from the database.

All the data will be synchronized if you store data in one region and access a global table in another. Any data in one table will also be present in the other.

Security is paramount with Amazon DynamoDB. Everything is handled, so we're not exposing anything. It offers controlled access, ensuring users have their data. If you have the necessary access rights, you can check the data. Otherwise, secret access is not granted. The cloud takes care of everything seamlessly.

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

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. 

Positive

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 solution to handle structured data. So, whenever you need to make a runtime call and send any data, you can create it. To store the data exclusively, we need to use granularity. You must integrate with Lambda to process and store the records, whether they're coming from Connect or elsewhere.

The most unbelievable feature is NoSQL. Unlike traditional SQL databases, DynamoDB doesn't require predefined schemas. You don't have to design the schema, which can be limiting in SQL databases. Additionally, in SQL databases, modifying the schema to add new columns can be confusing and must be done before adding new data. DynamoDB allows for flexibility in adding new attributes to your data at runtime without altering the schema. This makes data processing more efficient and customizable. The performance of DynamoDB is highly configurable, depending on the provisioned Read Capacity Units and Write Capacity Units that you allocate to your tables.

The solution could be cheaper.

I have been using Amazon DynamoDB for 6 years.

The solution doesn't break down.

The availability is very good. It is also scalable.

The solution is expensive.

DynamoDB is one of the services that 90% of people use on AWS.

Let's say we are developing an application using AWS. For the backend data storage, DynamoDB is the best solution AWS offers for NoSQL databases. If SQL is needed, then RDS is the way to go.

You must understand the basic CRUD operations of databases, along with the APIs. Knowing how to create a schema, determining primary and foreign keys is essential. The AWS documentation provides detailed guidance on these.

DynamoDB supports multiple areas and has good monitoring and security features. AWS CloudWatch can be used for monitoring, and third-party tools like Datadog or additional integration are available for functionality.

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

Amazon DynamoDB is used to store data in the form of JSON. I use AWS Lambda to insert data into Amazon DynamoDB.

In a relational database like MySQL, we convert values, like name, age, or other details about a person, into tables. We directly pass the JSON value to Amazon DynamoDB, which is why Amazon DynamoDB is faster than relational databases.

The solution's efficiency and performance should be faster than other databases.

I have been using Amazon DynamoDB for six months.

I rate the solution a nine out of ten for stability.

Amazon DynamoDB is a scalable solution that can store more data than other databases. AWS manages Amazon DynamoDB, such as increasing the storage, RAM, or CPU of its actual server. We need not worry about the solution's scalability. The solution's availability is 24/7.

The solution’s technical support is good.

I previously used Amazon RDS.

The solution’s initial setup is easy.

We can deploy Amazon DynamoDB in one to two hours.

The solution was free to use one month ago, but now it is a paid service. Amazon DynamoDB is not an expensive solution.

We can use Amazon DynamoDB for both on-premises and in the cloud.

Overall, I rate the solution a seven 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.

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.