4 ms·

Can you expand on that? This is my understanding so far, feel free to correct it: It looks like a good place for quick key-values lookups. It's a "table" as

Can you expand on that? This is my understanding so far, feel free to correct it: It looks like a good place for quick key-values lookups. It's a "table" as a service, with 1 (or 2) columns that you can index on. Anything else and you need an RDBMS. It's useful for simple storage, without the overhead of setting up an RDS.

blowski 5y ago
The problem is that at the low-end where you just want something cheap and simple, it’s too complicated compare to Aurora. At the higher-end where you want something with extreme-performance, it’s got too many weird edge cases. If you have a team of people that know how to use it well, I’m sure it’s an excellent tool. But it shouldn’t be casually thrown into an architecture, because there is nearly always a better solution.
isbvhodnvemrwvn 5y ago
The issue is that the keys can be used to various extent to handle relational data (this re:Invent video shows this well: https://youtu.be/HaEPXoXVf2k?t=1363 https://youtu.be/HaEPXoXVf2k?t=1363). What people miss though is that in order to not shoot themselves in the foot, you have to have stable, known access patterns which meet the constraints of DynamoDB. Even the documentation of DynamoDB says so: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html https://docs.aws.amazon.com/amazondynamodb/latest/developerg... This means that it's a good use case for shopping cart of Amazon since there's limited innovation possible there and it fits the bill nicely, but for a new application with relational data where the requirements change all the time - it's a terrible, terrible choice for which you will pay dearly.
jugg1es 5y ago
It is really way more than a 'table' as a service if you design it right. It is actually your entire database as a service if done right. AWS actually has some great documentation in this regard.

blowski 5y ago

The problem is that at the low-end where you just want something cheap and simple, it’s too complicated compare to Aurora. At the higher-end where you want something with extreme-performance, it’s got too many weird edge cases. If you have a team of people that know how to use it well, I’m sure it’s an excellent tool. But it shouldn’t be casually thrown into an architecture, because there is nearly always a better solution.

isbvhodnvemrwvn 5y ago

The issue is that the keys can be used to various extent to handle relational data (this re:Invent video shows this well: https://youtu.be/HaEPXoXVf2k?t=1363 https://youtu.be/HaEPXoXVf2k?t=1363). What people miss though is that in order to not shoot themselves in the foot, you have to have stable, known access patterns which meet the constraints of DynamoDB. Even the documentation of DynamoDB says so: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html https://docs.aws.amazon.com/amazondynamodb/latest/developerg... This means that it's a good use case for shopping cart of Amazon since there's limited innovation possible there and it fits the bill nicely, but for a new application with relational data where the requirements change all the time - it's a terrible, terrible choice for which you will pay dearly.

jugg1es 5y ago

It is really way more than a 'table' as a service if you design it right. It is actually your entire database as a service if done right. AWS actually has some great documentation in this regard.