[lmm]

No. If you're going to use serialisable you might as well just use something like Redis (which achieves serialisable behaviour by the much simpler approach of... actually executing your operations serially, and generally outperforms a traditional RDBMS set to serialisable transaction isolation). If you're going to use the horrendously complex machinery of a traditional RDBMS, it should be because you need a level of performance not achievable under serialisable isolation level.

[vlovich123]

Redis 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.

[lmm]

> 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.

[vlovich123]

Redis does not support indexes and all sorts of other things. It works well only for a specific kind of workload but isn’t as generic or flexible.

SSI gives you the performance of close to snapshot isolation with the safety of serializability. The lowest I would ever go is snapshot isolation and ideally SSI. Anything else I’d use an eventually consistent database instead because then there’s at least no pretense.