So instead of people using the right tool for the right job and learning single table design when using DDB, they are going to use the completely wrong tool. I can just imagine the sub optimal in memory aggregations and expensive use of read and write units.

▲

cammasmith 3 days ago | parent [-]

Valid points. The read cost and in-memory aggregation concerns are real and worth flagging. DynamoSQL is index-aware and will use your partition keys, sort keys, and GSIs where it can, but you're right that a well-designed native access pattern will be cheaper.

That said, not everyone using DynamoDB has the luxury of designing perfect access patterns from the start. Real production tables are often messier than the textbook examples. And for analytical or exploratory work (e.g. understanding your data, debugging a production issue, running ad-hoc reports) a slightly more expensive read is a reasonable trade-off for writing SQL in seconds rather than SDK code in minutes.

I appreciate the feedback. The cost visibility question is something worth being clearer about in the docs.

▲

raw_anon_1111 3 days ago | parent [-]

For analytical are exploratory work, it still would be much more sensible to use DynamoDB streams with a simple Lambda and write it to an Aurora Serverless Postgres/MySQL table.

The tradeoff of doing aggregations and joins in memory just isn’t worth it.

	▲	cammasmith 3 days ago \| parent [-]
		I agree for cases that need real-time replication and are querying at high frequency. There is a trade-off, though. You're adding three services to maintain, there's replication lag, and Aurora's running continuously whether you're querying or not. For teams that need occasional analytical access to their DynamoDB data without building and operating a replication pipeline, I still think the in-memory trade-off is worth it. Different teams, different trade-offs.