3 ms·

Designing application specifically for DynamoDB will take _a lot_ of time and effort. If you can write, read, and query a JSON document using an API in your ap

Designing application specifically for DynamoDB will take _a lot_ of time and effort. If you can write, read, and query a JSON document using an API in your application, it's literally that simple. The only real time and effort is the architectural decisions you make up front, and that's about it. And there are some great guides out there that cover 99% of those architectural decisions. As a user of both, I find MySQL replication and clusters to be far more complex and time and effort intensive.

kdazzle 4y ago
> 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)
i_love_limes 4y ago
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)
- blantonl 4y ago
  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.
nkozyra 4y ago
> 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.
lumost 4y ago
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…

kdazzle 4y ago

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

i_love_limes 4y ago

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)

blantonl 4y ago
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.

nkozyra 4y ago

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

lumost 4y ago

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…