Their paper talks about a lot of the same things I do, and if you read both, you can see the nature of the tradeoffs they make and where the pain points are still hiding.
For instance, carefully choosing regions close together to show transaction commit times which are not horrible. But if your region distribution is not ideal...
DSQL looks like a Big Deal to me - solving the essential scaling bottleneck that relational DBs give you without ending up with a weird system like dynamodb that no one wants to use.
DSQL has some serious limitations (transaction size, but also others). I would say working with it feels more like Dynamo than Postgres.
Which is fine - it is a specialized system designed for specialized problems, not a drop in replacement for Postgres that would make your application magically multi-region.
Also, I'm not sure if it actually solves any scaling bottlenecks. Any distributed system that needs to reach consensus will be as slow or slower than single node, which does not need to do it. Yes, usual implementations only go through consensus for writing and reading isn't constrained ... but you can already do that with read-only replica of a normal database.
For me, the primary issue with it is that I have zero intention of getting locked in to AWS. All the marketing looks great, but I don’t invest energy learning tools I can’t run locally. I’m happy to use AWS but only if I can see the exit. This doesn’t offer near enough to make me break that rule.
I literally just wrote a blog post which explains the kind of problem they're trying to solve and why any solution is just choosing where the pain is.
https://gtowey.blogspot.com/2026/07/why-are-databases-so-har...
Their paper talks about a lot of the same things I do, and if you read both, you can see the nature of the tradeoffs they make and where the pain points are still hiding.
For instance, carefully choosing regions close together to show transaction commit times which are not horrible. But if your region distribution is not ideal...
DSQL looks like a Big Deal to me - solving the essential scaling bottleneck that relational DBs give you without ending up with a weird system like dynamodb that no one wants to use.
Why aren't more people talking about it?
DSQL has some serious limitations (transaction size, but also others). I would say working with it feels more like Dynamo than Postgres.
Which is fine - it is a specialized system designed for specialized problems, not a drop in replacement for Postgres that would make your application magically multi-region.
Also, I'm not sure if it actually solves any scaling bottlenecks. Any distributed system that needs to reach consensus will be as slow or slower than single node, which does not need to do it. Yes, usual implementations only go through consensus for writing and reading isn't constrained ... but you can already do that with read-only replica of a normal database.
I feel like a lot of the trade-offs forced on you by dsql, you are forced into when scaling Postgres.
Like if I’m an SRE/DBA and you running massive update queries in a single transaction, that is the first thing I’m getting rid of.
For me, the primary issue with it is that I have zero intention of getting locked in to AWS. All the marketing looks great, but I don’t invest energy learning tools I can’t run locally. I’m happy to use AWS but only if I can see the exit. This doesn’t offer near enough to make me break that rule.