I don’t think I need NoSQL. It’s just that I hate having to map my structured data into tables and rows and joins and schemas and primary keys. A document|object|key-value store just usually maps better to the data I’m trying to model than a trumped up spreadsheet that requires me to speak a foreign language to it. Other’s mileage may vary of course. Just been my experience in the domains I’ve worked in.

(Ironically, I agree very much with your general sentiment, just not the example of illustration you chose)

You can do those in most SQL databases too, with the option of structured data if some of your data fits it

> having to map my structured data into tables and rows and joins and schemas and primary keys

You don't have to. You can just use JSONB.

I wish I could justify using SQL more. It's just way too easy to use Dynamo. Unless my data is complicated enough to warrant a relational model, it's going in Dynamo.

I don't disagree, it is so easy to build solutions on tp of dynamodb - and then I regret it when the access patterns change and the solution falls apart -thats when I wish I had stuck with tried-and-true relational.

That is kind of the problem, DynamoDB - and other NoSQL database - allow you to just start building your app, without any real thought about what data you will need and how it will be used - but you are often shooting yourself in the foot to not map this stuff properly out in advance.

> don't assume you need a NoSQL solution

Likewise, people who only know relational DBs shouldn't assume they need an SQL solution. It's remarkably rare that you encounter engineers with real thoughtful experience with both and they have the experience to know which tool to pick up for different problems.