alt Hacker NewsRedis doesn’t support rollbacks so on a conflict, you’re left in a potentially inconsistent state, which is precisely what serialized transactions are supposed to prevent. Additionally, you’re very limited in the kind of logic you can express within a transaction safely unlike SQL where you can make decisions based on past reads remain correct or unapplied whereas redis can do nothing here - once you’ve scheduled a transaction it’ll complete all the operations you enqueued even if a racing operation altered the underlying data that drove the decision.
Pretending like redis is suitable for an RDMS workload because it executes things serially means you’re completely ignoring what transactions are actually used for and how they work.
> you’re very limited in the kind of logic you can express within a transaction safely
On the contrary, you have Lua which is much more expressive than SQL (yes Turing completeness, but there's a huge difference in how easy it is to read and understand).
> Pretending like redis is suitable for an RDMS workload because it executes things serially means you’re completely ignoring what transactions are actually used for and how they work.
Well the vast majority of RDMS workloads don't use serial isolation, that's part of my point. As for the rest, all I can say is I've worked on many systems in many industries and seen very few (honestly none) that actually made effective use of what transactions do and don't give you.