Conversation

Fascinating disconnect I’ve seen on this one: - academic researchers: SERIALIZABLE isn’t the default? But everyone enables it first thing, right? - database users: SERIALIZABLE exists?

Quote Tweet

Brent Ozar

@BrentO

Sep 13

"Why isolation level serializable is not the default?" reddit.com/r/Database/com Oh my.

115

Replying to

SERIALIZABLE may perform quite well on average, but is more prone to pathological performance issues from deadlocks, retries, and so on (as a general rule). So while arguments like "the safest isolation level should be the default" have validity, they also cut both ways.

Replying to

and

In other words, it's not so much a cultural difference around how much correctness is emphasized over other things. More like a difference in how correctness is defined or understood.

Replying to

and

Can you elaborate on what you mean with 'a difference in how correctness is defined and understood'? At first sight this seems like a self-contradiction. What am I missing?

Replying to

and

operations at scale, i think. not the typical definition of "correctness", bit broader of an idea, but the amount of broadening that peter just did seems to be pushing it in my view :)

Replying to

and

Academic researchers and DB practitioners do see eye to eye on (say) how guarantees around durability ought to work. Isolation levels are different, somehow. That's my point. Speculation: if you make serializable the default, many more users complain "my DB is broken".

Replying to

So ISTM that it's not primarily about winning on benchmarks at any cost. It's about what application developers are willing to tolerate in the real world. (I'm not taking a position on what application developers *ought* to do. This explanation seems to fit best, is all.)

Replying to

Yugabyte recently introduced support for READ COMMITTED, to great fanfare. This was all about developer experience and compatibility -- AFAICT it had precisely nothing to do with performance. See

theregister.com

YugabyteDB adds read-committed isolation levels

It's easier than retraining PostgreSQL devs, says distributed relational database startup

6:30 PM · Sep 14, 2022Twitter Web App

Replying to

Right. Pessimistic vs optimistic locking may be a performance decision. Read Commited is about not having to build a retry logic in the application (at the price of having to think about race condition correctness) of course a bad retry logic may be bad for performance

Replying to

One variant of this, a packaged app that you deploy. Can’t change the app. Must use the isolation level expected by the vendor.

Show replies