[jchw]

I'm more interested in solutions like Spanner and Cockroach. Different tradeoffs for different applications, but they seem to be the most general purpose of the highly scalable databases. DynamoDB is cool and I've tried to adopt it for things, but it's surprisingly hard to imagine an application where the model isn't somewhat limiting. The capacity provisioning is also quite painful, which doesn't help matters any.

[jchanimal]

The databases you mentioned both have strong consistency, but do not have serverless pricing models. My employer FaunaDB has a similar consistency model, but a pay-as-you-go model that requires no provisioning or capacity planning.

You can read more about our ACID transactions here: https://fauna.com/blog/consistent-transactions-in-a-globally...

[jchw]

Pretty cool. Of course, the serverless version doesn't have too many regions yet, so some of the advantages of strong global consistency may be less useful. But I'll keep my eye on this regardless.

[p0rkbelly]

I think it is a worth noting that there is a difference between Dynamo and DynamoDB. One is a powerhouse academic publication that shook up modern computer science and one an enterprise tech product based upon Dynamo.

It is the 10th anniversary of Dynamo as a CS milestone.

[jchw]

I understand that, I'm mostly just replying to the "As we say at Amazon, it's just day one for DynamoDB" line. I do respect that Dynamo is certainly an achievement in thinking outside the box. But as for DynamoDB's place in the future of databases, I'm betting against it due to the lack of versatility for workloads that aren't purely non relational. Can't even do log style stuff due to the way sharding works :(

[moduspol]

I'm also excited for Spanner and Cockroach, but even at a high level, DynamoDB is essentially requiring you to design how you're storing your data based on how you will access it, how it will be sharded, and how it will be pruned. That makes a lot of use cases tricky, but the end result is that if you design right, it will scale linearly quite well.

It feels like using a relational model (with SQL) is fundamentally different in that you're designing how you're storing your data based on how it relates to other data. It's certainly a whole lot easier to design for, but it makes me wonder if it is possible to close that gap in terms of "easy to design / SQL / vertically scalable" and "serverless / cheap / horizontally scalable".

[duggan]

Capacity provisioning was the most annoying aspect of using DynamoDB when I last worked with it, but in the last couple of months they've added autoscaling[1] which would seem to address that major bugbear (with the caveat that I haven't had reason to test it out yet ;)

[1]: https://aws.amazon.com/blogs/aws/new-auto-scaling-for-amazon...