Amazon DynamoDB Reviews

Our main use case for Amazon DynamoDB is storing quick metadata information about any of the image artifacts that we collect from our customers. We generally store this in Amazon DynamoDB in multiple regions for multiple customers.

Amazon DynamoDB is easy to use because of its nature of scaling and IO, and everything is very fast. You don't have to manage anything, and all that burden is on AWS, so it is very easy for us. Guidewire itself has a wrapper around AWS services and also Amazon DynamoDB where we consume the wrapper and directly have all these resources created with Terraform scripts.

The best features Amazon DynamoDB offers are its performance and Global Tables, which stand out because of their capabilities and speed. The features of Amazon DynamoDB have helped us because the data we are storing is not very large. Postgres is not a database we could use for that because there are no relationships. Scalability is really cool because you don't have to worry about anything, and sometimes on an ad-hoc basis, if we have to store something extra, we don't have to think much and can move forward. It also doesn't cost a lot.

Amazon DynamoDB has positively impacted our organization. As a whole, I feel it's very good. Amazon DynamoDB has made things easier and more efficient for our team because it's helpful as it scales and it's easier to use.

The only challenge I face with Amazon DynamoDB is that with the partition key and secondary key, the query doesn't become very easy. The construction of that schema is a bit tricky because once you need the data back and want to query, you only have the primary key and the secondary key, and nothing else you can query with. I think that's a tricky part, and apart from that, Amazon DynamoDB is really cool.

To improve Amazon DynamoDB, the challenge I faced is that you cannot essentially query with anything that you want from the table. I think if that capability was there, then it would be really helpful to push any sort of data and not worry too much. Now, to push some data, we have to think about whether we can query it back, or else we have to go for Postgres while we use SQL there.

My team has been using Amazon DynamoDB for a long time. By the time I came, they were already using it, but as a whole, Guidewire has been using it for a very long time because Guidewire is completely built on top of many AWS services.

In terms of scalability, Amazon DynamoDB handles increases in data and traffic well for our team. To be honest, we don't have a lot of traffic for our product, so we haven't seen a lot of spikes in the IO calls that we make to Amazon DynamoDB, but as far as I've seen, Amazon DynamoDB and its scaling features really provide very good capabilities.

As for customer support for Amazon DynamoDB, being part of a very large organization, these things are carried out by different teams, so we don't have any interaction with AWS directly.

In general, it feels easier to use Amazon DynamoDB, but I don't have anything else to compare it with. If we had used something else and then switched to Amazon DynamoDB, I would have compared it and could have given you some metrics, but currently, we have been using AWS services for a very long time, and I don't have anything to compare it with.

I don't know if there were any trade-offs about choosing the cloud provider itself and the services in the cloud providers at that point in time, but before Amazon DynamoDB, we have been using AWS services for a very long time, and we also have wrappers around all these services.

My experience with pricing, setup cost, and licensing for Amazon DynamoDB is that I'm not very sure about it. I'm in the core backend team, and I think there is a different team that handles all of these things. Since we have had AWS services for a very long time, all of this would have been set up a lot earlier than I joined the organization.

Amazon's documentation is the best documentation I've ever had. Generally, I go for LLM support, but AWS has very good documentation that I directly come and see to understand any of the services that they provide.

I would recommend Amazon DynamoDB to others looking to use it, also because of its free tier. Apart from my organization, I have also considered using AWS services personally because they provide a free tier initially, and I think AWS is the best option because of its cleaner documentation, it's easier to use, and has all the SDK support for developers. I rate Amazon DynamoDB a nine out of ten because it's very good as far as I've used it, but the only thing is that all the data that we want to get back is a bit tricky. Pushing the data into Amazon DynamoDB is easy, but getting it back is a little more complicated, and I think that is what keeps it a bit back from a perfect score.

A specific example of how I use Amazon DynamoDB for data storage in my work is that we use it in correlation with Amazon Connect customer, in which we use it for storing CTRs related data; we also use it inside the flow for storing values and customer-related data.

One of the best features Amazon DynamoDB offers is the replication, specifically multi-region replication, which keeps it perfectly in sync with Amazon.

Amazon DynamoDB has positively impacted our organization because it is relatively cheaper than other storage databases, it provides querying support, and since it is non-structured, we do not have to worry about structuring our data as we would with other SQL supports.

I would also like to see improvements in indexing in Amazon DynamoDB because when we change the indexing, it takes quite a bit of time, and we lack joins in the table; additionally, we have query limits concerning how much we can query at one single time, which becomes expensive when dealing with a large dataset, such as when we had around 10 million rows, and scanning that table was very costly.

I have seen improvements in performance after using Amazon DynamoDB as we have indexing, which makes retrieving data very fast; in terms of cost, we use on-demand billing, so we pay per request, which is really cost-effective for us, and it has been excellent to integrate Amazon DynamoDB into our architectures rather than relying on other database supports.

I am a technical consultant working with AWS cloud, integrating tools into the cloud. As an SRE engineer, I primarily deal with AWS services such as EKS and Amazon DynamoDB. My main responsibility is ensuring our infrastructure remains operational at all times.

The strategy ensures customers never experience problems since the infrastructure is provided by AWS. From the customer's perspective, they never have to depend on a particular database. In terms of availability, it remains consistently high.

Amazon DynamoDB is readily available, and we do not have to worry about downtime unless there is a global outage. From a cost perspective, it presents a challenge.

The primary feature is constant availability without concerns about server maintenance or ensuring database uptime, as AWS manages everything from their end. We simply set up the database and allocate it to customers according to their requirements, making it an easy and smooth transition.

Regarding security, being in the cloud provides numerous security features. Amazon DynamoDB operates at the backend within our three-tier architecture. We have front hosting, business logic or application server in the middle, and databases at the backend. Additionally, we implement security layers such as SSL, creating a highly secure environment.

The solution has proven to be reliable thus far.

All features have proven effective so far. The main area requiring attention is the cost aspect. If they reduce the cost, it would be exceptional.

The features we currently use meet our requirements, and we utilize them thoroughly. There might be additional features we have not discovered yet, as it is impossible to use all features completely. Our team has been using it for two years and continues to explore. We expect to discover more use cases in the future.

I have been working with this solution for over two years. Prior to this, I worked with different tools.

Issues occur rarely. We have a dedicated database team managing everything. We contact them when the team needs information about new features or during version upgrades.

The solution is scalable and performs better in terms of scalability.

I would rate customer service as seven because the process we must follow can be lengthy. Sometimes we cannot connect with the correct team to resolve issues. This area could use improvement.

Positive

I have used other solutions and continue to explore additional options.

The setup was straightforward as it is managed by AWS cloud.

I am currently reading and exploring ways to implement these solutions into container technology. I previously worked with Cisco and am planning to harden and implement these into container technology. I have hands-on experience with Cisco FT, specifically the Firepower 1100 series.

I worked completely with cloud tools while simultaneously gaining hands-on experience during my master's program at university. For disaster recovery, we have mapped infrastructure A to a different site in infrastructure B. We have implemented a DR strategy across three sites, allowing quick migration if one site fails. We also handle communication between different AWS resources.

I rate Amazon DynamoDB a nine out of ten.

Positive

We use Amazon DynamoDB for data lookups with the consultancy.

Scalability has significantly enhanced data retrieval speeds. The integration capabilities with other AWS services enable a smooth, easy process. This ease of integration is particularly beneficial for applications and websites where data lookups are needed. The solution supports these lookups efficiently, assisting in managing large volumes and enhancing productivity.

The user interface could be improved to make it more intuitive. From a design and solution perspective, it's really good, but the interface always has room for enhancement.

I have experience with Amazon DynamoDB on and off for the last four years.

I would rate the stability of this solution as eight out of ten.

Scalability is the most valuable feature, and I rate it a ten out of ten.

Technical support is quite good, with a rating of eight out of ten.

Positive

The initial setup of Amazon DynamoDB is straightforward. While it can vary from use case to use case, it is generally not complex to set up.

In-House

From a sales perspective, we do not make money from the service itself. AWS makes money from Amazon DynamoDB, and our involvement is more about professional services engagement.

The price of Amazon DynamoDB is fairly priced in relation to the market.

I highly recommend Amazon DynamoDB to others. Although Amazon DynamoDB is excellent for data storage and lookups, it is not intended for analytics. It stores data and supports data lookups from applications and websites.

I use the solution in my company as a fast storage system. Since there are some serverless functions, we used to write the outcome of those into the Amazon DynamoDB. My company then used to receive it later from the other apps. It mostly does fast retrieval and acts as a good storage system.

The most valuable feature of the solution is its performance.

Previously, when in my company, we used to store 64 KB of data, we used to get problems and errors, and due to such reason, at such a point in time, we had to find a different storage system or modify the system so that the size of the value is not more than 64 KB. The main aforementioned issue in the tool can be considered for improvement for Amazon DynamoDB. In our company, we have some data which can be stored as we want. Previously, only 64 KB could be used, and later, I think, it was about 400 KB. If the tool could have an additional 10 MB to offer, then the tool could be easier to use. The tool is a key value storage, where the key will be long. In terms of value, we couldn't store more than 64 kb previously in the tool, but later on, it was increased to 400 KB, which is a limitation that I don't like in the tool.

I have been using Amazon DynamoDB for five years.

It is a stable solution.

In our company, we don't have to manage anything. We don't have to worry. We have never failed with the tool due to any performance issues. The only problem is with the size or the value. For performance, we don't have to worry. It is a scalable solution.

In my team, there were around 13 people using the product and using the storage services from Lambda or serverless functions, as temporary storage and high storage, but the tool's limitations impacted all of them, so we came up with some other solutions due to its 64 KB limitation. In some of the serverless output, in which tool the data can be less than 64 KB or maybe if we consider the current situation involving a tool that offers less than 400 KB storage. In some cases, we think that there could be dynamic data storage, or if our value is more than 400 KB, then we don't use dynamic storage in such areas.

When my company faced an issue with the tool, and we wanted to call the solution's technical support, I saw the documentation stating that 64 KB is the limit.

The product's initial setup phase is very easy since everything is related to the cloud.

I think that if we have our own server or something like RocksDB or some other storage, then from what I remember, I can say that Amazon DynamoDB's price is for the requests or how much time we drive our storage, but it was not expensive. We managed the cost over there, and we didn't feel it was expensive. I can say that it is not the cheapest one because if we had our own kind of storage solution, our own hosting, and instead of using the cloud, we opted for some other method, it would have been a tool of a lower cost.

My company started to use Amazon DynamoDB since we need cooperation between the main applications and Lambda, but as we don't have the steps, we want to store it somewhere else. In general, we want very fast storage and retrieval, and we found that Amazon DynamoDB is a good solution during our research and works well.

I recommend you use the tool. I don't think there is an issue using Amazon DynamoDB. We only have to consider the value size limitations of 400 KB. If you want to install more than 400 KB of data in a value, obviously, we'll have less value in the key. But suppose there are a lot of big values in the key value storage type. We need to consider whether the value is predictable and whether it exceeds 400 KB.

It is very easy for beginners to start using the product.

The feature of the product associated with global tables is something that is used only for the replicas. Most of the time, we only have the replicas being available on EC2, so we do not need to make it available through the different availability zones or regions. We made some replicas to make the tool stabilized. We don't need to have replicas for different reasons because all our customers who use those are from the US, and some specific regions.

For monitoring and security features, my company normally uses CloudOps and other different tools like Datadog. My company has not directly used anything from Amazon DynamoDB for monitoring.

For performance, I rate the tool a nine and a half out of ten. Considering the value storage limitation, I rate the tool an eight out of ten.

We use Amazon DynamoDB to track account IDs, address ranges, and descriptions. It is primarily used to automate the process of maintaining our about 1,120 AWS accounts. We also use DynamoDB in production for a pretty large-scale product.

Amazon DynamoDB has been a reliable service that is very performant and meets our expectations. Its automation capacity reduces the need for more personnel, which aligns perfectly with our strategy of focusing on serverless services. The ease of data replication between regions is a significant benefit since it was already integrated into the solution.

We use the single table design pattern extensively since it helps us describe very complex patterns and data types on the table. 

Additionally, we use streams to synchronize data between global tables across regions and AWS Backup to back up our tables.

Defining simple expressions and queries can be slightly complicated due to DynamoDB's unique JSON syntax. This can be confusing, especially for beginners.

I have been working with Amazon DynamoDB for about three and a half years.

Amazon DynamoDB is very stable, and we haven't encountered any issues or downtime.

In terms of scalability, Amazon DynamoDB performs excellently even during high traffic demands, fitting our expectations well. We rate the scalability at nine out of ten.

Generally, customer service is okay and helpful. However, there is room for improvement in understanding the customer's specific use case, as they sometimes only refer to documentation we have already reviewed.

Neutral

Our architecture was cloud-native from the beginning, so DynamoDB is the foundation of our cloud setup.

The initial setup was easy due to the use of infrastructure as code tools. The process involves a design phase, code preparation, and automation through CI/CD pipelines.

The deployment required a design phase handled by one person and another person providing information. Overall, it required about two people for two weeks.

The return on investment stems from the reduced need for personnel due to automation and the built-in data replication feature. We did not have to implement additional ways to handle region replication as it was already integrated.

Amazon DynamoDB can be a little expensive. I'd probably rate it at seven out of ten on the cost scale. However, it is reasonable since the automation reduces personnel costs.

Learn how to use a NoSQL database like DynamoDB by implementing data models using single table design patterns. This approach allows users to manage multiple data structures efficiently within a single table.

I'd rate the solution eight out of ten.

We are a data classification company. We classify non-structured data, like documents in the organization. When we classify a document, we store the document's name and severity in Amazon DynamoDB. If the document has a sensitive classification, we add a tag, which will connect with the company's CM so they can send that document out of the company. We store all the document data on Amazon DynamoDB.

The transactions are very fast, and the cost is low with Amazon DynamoDB. We also have a web platform where we show our clients all their data. When we use DynamoDB with OpenSearch for other searches, we see that the platform is faster.

The process of making a query could be optimized. Sometimes, it can be difficult if you don't design it properly at the beginning of the project. It's more expensive to look for a field in your database than when you look for it in a relational database.

The solution should find another way to handle the queries. Counting all your data or the number of fields you have in a relational database is easier than in a non-relational database.

I have been using Amazon DynamoDB for two years.

The solution's scalability is very good. We don't have problems using Amazon DynamoDB with small clients, and it also scales perfectly for bigger clients.

The solution’s technical support is very good.

Positive

We previously used MongoDB. We switched to Amazon DynamoDB because its cost is lower.

It is not complex to deploy Amazon DynamoDB. The complex part is making a proper design and understanding how your application is going to grow because you have to map all these scenarios at the beginning. It could be hard to make changes in the initial design.

I didn't take part in the solution's setup. We have a DevOps team that does the configuration. In the setup, we try to design properly so that we can relate the field that can optimize the queries in the future.

In the past, we paid more for MongoDB, but now we optimize our searches and how we store the data on DynamoDB. We previously paid around $20,000 a month for MongoDB, and now we're paying just $4,000 monthly for Amazon DynamoDB.

It's easy to maintain the solution. We had some issues with the backups because DynamoDB has internal backups or restore points. We're trying to have backups with AWS, which is more expensive than having the backups in DynamoDB.

We're also trying to make a configuration with Lambda functions to save the backups into S3, but that is more expensive than an AWS backup. I don't know if there is another way that we can have that backup. When we have to put in progress a disaster recovery plan, we can have those backups.

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

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. 

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.