Did a project with Dynamo last year. Hope never to see it again.

Compared with RBMS tooling looks like a high school project.

DynamoDB has had major improvements in the last few months: e.g. you get dynamic capacity provisioned tables (avoids re/write capacity exceeded exceptions because of capacity planning uncertainty), and transactions, to name two. However, even if you have a hosted RDBMS it has an implicit read and write capacity throughput that you need to design for (e.. hotspots in partitions), you just hit it a bit later in your project. The bounded latency at scale (throughput, and size of tables) is the main win for DynamoDB.

It couldn't possibly because they're trying to push use of their own technology to force dogfooding.

That might make sense if they didn't also offer a plethora of their own built-in-house as well has managed oss relational DBS.

None of those OSS relational DBs offer Amazon lock-in the way DynamoDB does - it's more reliable income if someone uses it, but it also takes more convincing for people to use it. What enterprise would use it if Amazon themselves don't?.

This argument makes no sense at all. What does lock in have to do with Amazon dog fooding its services? They're... trying to lock themselves in? What?

Amazon owns Dynamo DB, and make it available via AWS. If customers use it for non-trivial applications, they have some degree of lock-in, because they can't just migrate to another (self-)hosted instance of e.g. Postgres, MySQL, Oracle, Mongo, what have you.

So Dynamo is an opportunity for Amazon to generate lock-in through their own proprietary software.

But big and likely even medium size businesses are less likely (compared to tiny companies that barely go above the free threshold) to use a new technology without any big well known users, or publicly documented use-cases etc.

One big way companies can provide some confidence to potential customers about their technology is by dogfooding: they use the thing they're trying to "sell" (regardless of whether it's a licence, a service, whatever).

Your average dev is not making decisions based on what might work best for one particular problem Amazon has.

Do you think all of the companies that chose Cassandra and Dynamo were wrong to do so? There's no use case for NoSQL? There were no lessons learned, value adds from NoSQL?

How do you explain the 'NewSQL' approach, which seems to be so clearly borne of what we've learned from NoSQL?

It should be obvious that NoSQL has value, regardless of the issues with one of the earlier NoSQL DBs.

I don't see a value other than fashion driven development, specially when comparing the bare bones browser GUI for Dynamo with something like SQL Server Management Studio or that whole story with primary and secondary indexes, with prices being set by index usage.

The Cassandra design was always a bit of a frankenstein without clear upside to me, but the nosql craze started great conversations.

There is certainly merit beyond fashion to the dynamo architecture, and there are workloads where (for example) HBase is simply the correct type of tool despite the lack of polish of its management interface