Have to disagree on this one. Something as basic and out of the box as a migration / data backfill is not only complicated but also very expensive (both time and cost wise) on Dynamo. Not to mention all the other things that come nicely with an relational db (type checking, auto increments, uniform data)

To be fair, the parent discusses designing an application to use Dynamo, not data migration.

I'll completely agree with you on migration / backfill. You're going to pay a lot of money to migrate a ton of data into Dynamo, and you'll also definitely increase the complexity in provisioning and setting up that migration pattern.

But my comment stands pretty well considering greefield application development around Dynamo.

> If you can write, read, and query a JSON document using an API in your application, it's literally that simple

You could say that of Elasticsearch or Mongo, too. And it might be technically true, but you haven't scratched the surface of mappings, design, limitations, etc.

You can dump a bunch of data into Dynamo very easily, but what about getting data via secondary indices when you can't get your data with the views you've built without scanning? How do you use partition keys in it? And so on.

> The only real time and effort is the architectural decisions you make up front, and that's about it

And dont forget about the time spent fixing what could have been caught by types and regular old db constraints (for most applications)

It’s a question of change resilience. You can implement crud on a single object with ddb trivially. You can’t implement 5 different list by X property apis trivially, or filter the objects, or deal with foreign keys…