The Pros and Cons of DynamoDB

## Con: Weak querying model Global and Secondary Indexes can only get you so far. If you know your access patterns, this can be manageable. But if you don't, then it's difficult, nigh impossible, to build an ad-hoc querying system like you can build with traditional RDBMS or fuller-featured NoSQL systems like MongoDB. … During development phases it's not uncommon to have similar situations and with DynamoDB that could result in an unexpected bill, whereas with an RDS or Aurora instance, you'd see the same cost each month regardless. To some, being consistent is better than being cheap. … ## Con: Lack of server-side updates Sometimes you have to make changes against a bulk set of records. Perhaps there was a change to your data model, like going from a `.fullname` field to `.first_name` and `.last_name`. To do this, you must update each record individually. This may not seem too bad at first, but after a large enough set of records it becomes an untenable solution. Ultimately, you'll probably find it better to do data migrations on-demand in your API, as records are being read out of the system. … ## Con: Provisioned throughput and batch jobs don't work well together. Until recently, you had to tell DynamoDB what your read/write throughput would be, and this is how your DB was sized and priced. However, if you are running any recurring batch processes that do a large amount of read/writes in a short amount of time, your normal throughput levels will likely lead to write errors or throttled reads, neither of which are good. … Also, you need to model your data differently than you're used to with an RDBMS. One of the most common problems I run across is systems that try to fit a third normal form schema into DynamoDB, and it will fail horribly every time. If you're coming from another NoSQL system, like Mongo, you're likely to be more familiar with the modeling changes.