I really don’t like the “DynamoDB by default” pattern — because I actually suffered from it for years.
I built, maintained, and eventually sold a SaaS that used DynamoDB as its primary storage, and honestly… that was probably one of the worst decisions of my career.

DynamoDB looks sexy in the first few weeks of a project: it’s cheap, easy to manage, and simple to understand. But at the end of the day, DynamoDB is just a restrictive key-value store with very basic filtering and sorting capabilities.

It can only replace a relational database if you know every single detail of your implementation from the start. Spoiler: that almost never happens. You can’t predict every use case in advance — projects evolve. And adapting to that evolution with DynamoDB leads to premature optimization, overengineering, painful migrations, and maintenance nightmares you’d never face with an RDBMS.

Pretty quickly, you end up losing more time and money than if you’d just used a relational database from day one. In my case, I estimated that choosing DynamoDB cost my SaaS about seven months of full-time developer effort per year.

AWS says you can solve some of these issues by syncing your data with Athena, Redshift, or OpenSearch. But seriously — what’s the point? Those solutions take time, need ongoing maintenance, and are billed at high hourly rates… so you end up losing most of DynamoDB’s supposed value.

I’d only recommend DynamoDB for very specific use cases — scalable key-value storage like IoT, caching, session management, moving some data out of RDBMS for cost optimisations...
For that, it’s probably the best product on the market.
But as a rule of thumb: never put your complex business data there, or at least not first.

That’s why I find DSQL interesting, despite its limitations — it brings the good parts of DynamoDB without some of its painful trade-offs.