Choosing Between Strong and Snapshot Isolation in YugabyteDB

The Cost of Absolute Consistency

When building a distributed system, the most expensive operation is often the one that ensures every node agrees on the exact state of a piece of data at this microsecond. In YugabyteDB, this is the tension between Strong Global Consistency and Snapshot Isolation. Choosing the wrong level for your workload can lead to unexpected write-write conflicts that kill throughput or stale reads that break business logic.

How YugabyteDB Handles Distributed Time

To manage transactions across shards, YugabyteDB uses Hybrid Logical Clocks (HLC). Unlike plain NTP, which can drift and cause ordering issues, HLC combines physical wall‑clock time with a logical counter. This lets the system maintain a causal ordering of events: if event A happened before event B, the HLC guarantees the system sees it in that order, even with minor clock skews between servers.

Strong Global Consistency

Strong consistency ensures that any read returns the most recent committed write. This is achieved via the Raft consensus algorithm. A write must be acknowledged by a majority of the Raft group (the replicas of that tablet) before it is considered committed. A strong read must also verify it is seeing the latest state, which can introduce latency in multi‑region deployments because of the round‑trip time required for consensus.

Snapshot Isolation

Snapshot Isolation allows a transaction to see a consistent version of the database as it existed at the start of the transaction. Reads do not block writes and writes do not block reads, making it ideal for read‑heavy analytical queries or reporting dashboards where a few‑millisecond‑old view is acceptable as long as the view is internally consistent (i.e., you don’t see a partial update of a multi‑row transaction).

Practical Comparison: High‑Concurrency Updates

Consider a ledger system with two operation types: a high‑frequency balance update (write) and a monthly audit report (read).

Implementation Example: Tuning Isolation

YugabyteDB is PostgreSQL‑compatible, so you can set the isolation level at the session or transaction level. To run a heavy report without impacting production writes, use REPEATABLE READ, which maps to Snapshot Isolation in YugabyteDB.

-- Run this in the ysql shell (psql) as a user with permission on the accounts table\nBEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;\nSELECT SUM(balance) FROM accounts WHERE region = 'north-america';\n-- While this query runs, other clients can still UPDATE the accounts table without being blocked by this read.\nCOMMIT;\n

Verification: Open two terminal sessions. In the first, run the above transaction. In the second, issue an UPDATE on the same rows (e.g., UPDATE accounts SET balance = balance + 10 WHERE region = 'north-america' AND account_id = 42;). With REPEATABLE READ, the update should proceed immediately. If you were using a stricter level such as SERIALIZABLE, the update would wait until the read transaction commits.

Limitations and Trade‑offs

Snapshot Isolation is not a silver bullet. The primary risk is the write‑write conflict: if two transactions read the same snapshot and both try to update the same row, the first to commit wins and the second aborts with a serialization error. Your application must catch this error and retry the transaction.

Additionally, very large transactions that touch thousands of shards can put significant memory pressure on the transaction coordinator, as it must track all participants in the distributed commit process.

Decision Summary

Use Strong Consistency for critical paths where reading a stale value leads to a business failure (e.g., checking whether a single‑use coupon has already been spent). Use Snapshot Isolation for reporting, dashboards, and read‑heavy workloads where throughput is more important than millisecond‑perfect freshness.