There are certainly use cases where nosql is very helpful - heavy writes, as a denormalized cache, simpler non relational data models etc http://highscalability.com/blog/2010/12/6/what-the-heck-are-...
There are certainly use cases where nosql is very helpful - heavy writes, as a denormalized cache, simpler non relational data models etc http://highscalability.com/blog/2010/12/6/what-the-heck-are-...
I've never really seen those issues unless there is a more extreme circumstance.
In my read of "web app", in most cases you want to push/data in and out of the database. And modelling 1:1 and 1:n relationships is pretty natural in my experience. Deeply nested relationships are a pain, but they're usually a pain in SQL too. Document-orientation helps here a bit, but with some drawbacks. Where I think it does fall over completely is analytics, and OLAP-like work.
I guess hotspots can be an issue. However, that implies considerable related transaction volume, which I'd argue DynamoDB can excel at.
If you're using a framework like Rails - then sure, DynamoDB is out. But so is Lambda. The pattern of SPA (React/etc), Lambda, and DynamoDB is what's emerging instead of those frameworks. Definitely agree it can't cover many cases, but covers a lot of ground for me
Most apps I write for my own business, or see in production at companies I work for use a mix of sql and nosql depending on what they are doing. Mongo seems quite popular for heavy write loads, while still supporting some indexing and querying. It's great for fan out also.
I often see teams and devs failing to use DynamoDB effectively only because they don't know/use best practices. It just needs more time.
What I don't like about DynamoDB is the vendor lock-in. Otherwise it's a great product and works really well for many use cases.