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

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.

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

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. 

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.

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.

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.

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

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.

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.

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

The pricing for larger databases is higher.

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.

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

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

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 solution has size limitations. It also needs to be more user-friendly. 

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. 

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.

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

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.