Re:Aurora DSQL: Scalable, Multi-Region OLTP
by loevborg on Wednesday July 29, 2026 @04:23PM
(#49102549)
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.
Re:Aurora DSQL: Scalable, Multi-Region OLTP
by pepperoni_pizza on Wednesday July 29, 2026 @04:53PM
(#49102940)
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.
Re:Aurora DSQL: Scalable, Multi-Region OLTP
by blm126 on Wednesday July 29, 2026 @04:44PM
(#49102836)
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.
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.
Re:Aurora DSQL: Scalable, Multi-Region OLTP
by gtowey on Wednesday July 29, 2026 @05:43PM
(#49103458)
For instance, carefully choosing regions close together to show transaction commit times which are not horrible. But if your region distribution is not ideal...
Why aren't more people talking about it?
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.
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.
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.