DynamoDB, hands down. The comparison of client API in the article is laughable. Even the author themself noted that making a wrapper API for a given use case is

DynamoDB, hands down. The comparison of client API in the article is laughable. Even the author themself noted that making a wrapper API for a given use case is trivial. To choose a persistence engine based on client API is shortsighted at best. For the very small/simple, literally anything can work well, and even query API complexity doesn't matter much when you only have four distinct query patterns. At the mid-to-high level, I wouldn't use either of them; I'd use a relational database system. At this level you are adding new bits of data, some that fit in existing tables and some that do not. Your assumptions about query patterns falls down as new use cases arise. SQL is insanely flexible and powerful at this level. At the extremely high level, it's DynamoDB again. MongoDB can't scale as well. Relational isn't as useful as JOINs will kill throughout. This is the model DynamoDB was built for: query loads for applications with more than 10 million concurrent users. Add in DAX and the only scaling limit is how much you're willing to spend. Most of us (let's be honest) end up making products that live in the first group where even a couple Raspberry Pi 4 SBCs with external USB 3 drives would be sufficient. 99.99% of the rest would be all set with a properly managed RDBMS. That last 0.01% will be highly bespoke anyway, so putting predictions in too much detail would be a fool's errand. To some extent it applies to all levels, but at the highest usage rates, the only real answer is "it depends."