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.

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

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.

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.

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.

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 don't have in-depth knowledge to suggest specific improvements for DynamoDB, however, I haven't faced any significant challenges so far.

The pricing model of the product should be improved. 

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

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.

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.

The solution could be cheaper.

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

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.

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.

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

The design patterns and the documentation for this solution could be improved. In a future release, we would like to see an improvement of the data push options as we sometimes experience blockers when moving data. 

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.

If you have no prior experience with this type of non-relational database, the syntaxes, implementation, or understanding may be difficult.

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.

There is nothing that I can think of for improvements.

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

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

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

Data integrity across availability zones would be a valuable addition. 

Currently, DynamoDB provides eventual consistency across availability zones, but strong consistency would be beneficial for certain use cases.

There is room for improvement in the pricing. A more tiered pricing structure would better accommodate different usage patterns. Similar to leasing a car versus buying it outright, there should be options for those with lower or higher usage volumes.

It would be nice to have some AI features in DynamoDB.

Amazon DynamoDB could improve by being more robust, having a better user interface and data management. Additionally, there is some limited functionality compared to other solutions, such as MongoDB.

In an upcoming release, it would be beneficial to show spatial data on the interface. There would is a very important metric for our company.

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

Amazon DynamoDB has a very complex configuration if you go very advanced.

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. 

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

The pricing for larger databases is higher.

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.

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 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.

AWS is forward thinking and always adding new features. I generally cannot think of an area of improvement.

To be honest, AWS and their people know way more about the hosting and infrastructure needs of software developers than me and my team. I can’t think of any features that that could additionally add.

If I were to pick on one area to improve and an area in which they are not equal to or superior to the competition, I would say the user interface. It is far more simplistic that Azure’s slick presentation.

Of course, that is by choice, like the Amazon experience. But there are instances where the next step is not as logically presented as in Azure.

I still maintain that AWS is the unquestioned market leader in regards to features offered and is always introducing new ones in response to what their customers ask for.

They also are leaders in price, ease of use, and support, making them the obvious choice for my company’s cloud IaaS provider.

DynamoDB doesn't provide server-side encryption, so we had to do it manually.

Any replication to other regions requires writing code. It's not so bad, but would be better to get a solution out of the box. 

We store some protected patient information in DynamoDB, and in order to keep it HIPAA-compliant, we have to encrypt it at rest. Some services such as S3, Redshift and SQS will do the encryption on the server side, but with DynamoDB, the client application had to do the encryption before writing to the DB, and has to decrypt when reading. This means that we need to manage encryption keys: we need to store then securely and rotate them periodically, which is extra coding and complexity.

As for cross-region replication, AWS offers a way to do this using DynamoDB streams and Lambda, whereas other databases such as postgresql enable to configure replication without coding.

We use the document database. The primary key is quite slow. The free tier is quite hard to use.

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

They could provide more information or training programs to deliver knowledge to the engineers about the components of relational databases similar to popular vendors.

The response time for data queries should be less than a second. The queried data is not required in normalization for parameter queries, password queries, or data that can be used frequently. 

It would be beneficial if the product can be made open source.