Curious, besides being a truly serverless and scalable database why else would one choose to model relational data in DynamoDB? For the 'single table design' scheme the author talks about you are in a world of hurt if you need new access patterns? which is highly probable for most systems.
I think there are some features of DynamoDB that are miles ahead of other databases:
- Billing model. Pay for reads and writes directly rather than trying to guess how your queries turn into CPU & RAM. Also able to scale reads and writes up and down independently, or use pay-per-use pricing to avoid capacity planning.
- Permissions model: Integrates tightly with AWS IAM so works well with AWS compute (EC2, ECS/EKS, Lambda) with IAM roles. Don't need to think about credential management and rotation.
- Queries will perform the same as you scale. It's going to work the exact same in testing and staging as it is in prod. You don't need to rewrite when you get four times as many users.
A lot of folks are worried about migrations, but they're not as bad as you think. I've got a whole chapter on how to handle migrations. Plus, one of the examples imagines that we're re-visiting a previous example a year later and want to add new objects and change some access patterns. I show how it all works, and they're really not that scary.
Already implied that in "truly serverless and scalable database". My point is that it would be very dumb to not use something like postgres for relational data unless you really need those dynamodb features.
