Isolation vs consistency

Databases use the word "consistent" for two different things. Isolation is about transactions that run at the same time on one logical database. Consistency in the replication sense is about whether a read sees the latest write when copies live in different places.

The big idea

Think of two separate dials.

• Isolation asks: can transaction T2 see T1's half-finished work? Can two transactions produce a result that no one-at-a-time order would produce? Levels include read committed, snapshot isolation and serializable.
• Consistency asks: given several copies, does a read reflect the latest committed write?

The dials combine. Serializable says the transactions behave as if they ran one at a time, in some order. Strict serializability adds one more rule: that order must match real time.

Walking through it

Two transactions, with real time shown in the trace:

10:00:00.000  T1 commits: balance 100 -> 70
10:00:00.005  T2 starts and reads balance: 100

Serializable allows T2 to be placed before T1 in the order, so reading 100 is valid. The order just does not respect the clock.

Strict serializability forbids that. T2 started after T1 committed, so T2 must see 70.

The table shows where common systems sit:

Spanner is strictly serializable. A Postgres primary at SERIALIZABLE is strictly serializable because it has one node. Its asynchronous replicas are not, because their reads lag.

Common mistakes

• Saying "consistent" alone. The word is incomplete until you name the isolation level or the consistency model.
• Thinking SERIALIZABLE fixes stale replica reads. Isolation governs transactions. It does not make a lagging replica current.
• Assuming strict serializability is automatic. Unrelated keys on some systems can fall short of it, so check the vendor's exact promise.

Check yourself

1. In the balance example, why is reading 100 allowed under serializable? Serializable only requires some valid order. Placing T2 first is valid even though it ignores the clock.
2. A Postgres replica runs at SERIALIZABLE. Is its read guaranteed to see the latest primary commit? No. The isolation level does not stop replication lag.

Key takeaways

• Isolation is about concurrent transactions. Consistency is about copies of data.
• Serializable means some order. Strict serializable means that order also respects real time.
• A single-node database can be strictly serializable, but its replicas may not be.
• Always name both the isolation level and the replica read path.

Further learning

Next, see how to pick a model for each feature in choosing a consistency model per feature.

The Jepsen project maps about twenty consistency models into a hierarchy, and it tests vendors against their claims.

Transactions and isolation covers the isolation levels in detail.