[lmm]

I mean you're not really making use of MVCC etc. at that point. Foreign keys are far less relevant because your transactions are all fully atomic, so it doesn't really matter if your data is in an inconsistent state in the middle of a transaction, and conversely you've got no risk of e.g. adding a reference to a row that another transaction deleted concurrently. Why not just use e.g. Redis at that point?

[mamcx]

This is a misunderstanding of what serializable in an ACID datastore does, neither that trust developers without FK is always trouble, and that the suggestion of Redis show how much is lost here.

Big point: Serializable not exist alone in a decent ACID datastore, and no, less strict rules for the MOST important thing you have(your data) is NOT a good idea.

Over and over again Acid RDBMS have proven that trying to "relax" the rules in pursuit of performance or worse, mystical holy grails that have never been right or correct for a primary datastore, is a mistake. And then people goes back to them, because is the best tool for ALL the primary data store jobs. ALL OF THEM.

Is like the mythical C developer that "not need safety", that at least has more chance of be possible (after MANY passes over the code) that a datastore without safeguards.

[lmm]

> Over and over again Acid RDBMS have proven that trying to "relax" the rules in pursuit of performance or worse, mystical holy grails that have never been right or correct for a primary datastore, is a mistake. And then people goes back to them, because is the best tool for ALL the primary data store jobs. ALL OF THEM.

On the contrary. The most successful RDBMS by far was MySQL in an era where it didn't have any kind of ACID (you could write the transaction keywords but they didn't do anything). As the story we're talking about now shows, RDBMSes are routinely deployed with transaction settings that their users don't understand, much less use; there are settings that would reduce bugs if anyone cared to use them, but no-one does. People cargo-cult the idea that they should be using an Acid RDBMS but they almost never actually want or need one.

[oscillot]

The success there had more to do with it being a) free, at a time when there were far fewer of those options combined with that it b) ran on windows. The enterprise's pathological windows use for developer machines and the state of apples devices at the time and the near non-existence of linux enterprise laptops which continues today meant that they had the perfect product for that moment in history. I cannot overstate this: the people making these decisions think an acid transaction is a felony and not a term of art used by some of their employees.

[trumpdong]

Serializable doesn't mean serialized. It means if two transactions access the same data, one must be delayed or aborted. It doesn't mean they all wait for each other.

[lukas221]

people mostly use RDBMS because they want the advanced querying that SQL provides, not because of the isolation levels

but ignoring that, serializable isolation level means the database acts AS IF the transactions are serial. but most databases in fact will execute them concurently, with careful tracking to make sure they appear serial

[Groxx]

TBH I think I've seen more database use than not specifically because it serves as the central race-resolver in a system, because doing that anywhere else is many, many times harder and more mistake-prone. Fancy querying has been much less needed (and is sometimes a significant code smell), and is often fully offloaded into a data warehouse style system to reduce the risk.

Sometimes though, yes definitely. It's hard to claim anything universal at all about databases.

(Unless you mean "being able to choose between different isolation levels", then yes, completely agreed. Very very few use anything but the default, somewhere below serializable, and it always concerns me unless they can describe exactly what they're intentionally allowing and why it's okay for their system. Most cannot.)

[zadikian]

> TBH I think I've seen more database use than not specifically because it serves as the central race-resolver in a system

But you usually don't need serializable for this, cause READ COMMITTED locks the rows during updates.

[vlovich123]

MVCC is not inherently non serializable. For example, Postgres adds serializability on top through SSI.

[zadikian]

Cause I want relations and SQL. But also I kinda get what you mean and would not use serializable in Postgres.