In a world of eventually consistent NoSQL databases and "read committed" defaults, CockroachDB makes an audacious promise: Serializable Isolation by default—the strongest isolation level defined by the SQL standard.

Serializable isolation means that concurrent transactions behave as if they executed one after another in some serial order. No phantom reads. No write skew. No anomalies that leave your data in an inconsistent state. The database handles the complexity of concurrency control so your application doesn't have to.

This guarantee comes at a cost: serializable isolation is traditionally considered expensive and slow. CockroachDB achieves it efficiently through a combination of:

• Multi-Version Concurrency Control (MVCC): Multiple versions of each row, enabling non-blocking reads
• Serializable Snapshot Isolation (SSI): A variant that detects and prevents serialization anomalies
• Timestamp-based ordering: Using Hybrid Logical Clocks to determine transaction order
• Write intents: Provisional writes that lock data during transactions

Understanding this model is essential for writing correct applications and debugging issues when they arise. Most distributed databases offer weaker guarantees; knowing what serializable buys you helps you appreciate when it matters.

Before diving into CockroachDB's implementation, let's understand what isolation levels are and why the choices matter.

The Problem: Concurrent Access

When multiple transactions access the same data simultaneously, anomalies can occur:

1. Dirty Read: Transaction A reads data written by Transaction B before B commits. If B rolls back, A has read data that never existed.

2. Non-Repeatable Read: Transaction A reads a row, then Transaction B modifies it and commits. A reads again and sees different data.

3. Phantom Read: Transaction A queries rows matching a condition. Transaction B inserts a new row matching that condition and commits. A queries again and sees a new row that wasn't there before.

4. Write Skew: Two transactions read overlapping data, make decisions based on what they read, and write to disjoint parts of the data. The final state violates an invariant that both transactions believed they were maintaining.

SQL Standard Isolation Levels:

The SQL standard defines four isolation levels, each preventing different anomalies:

Most databases default to Read Committed or weaker, leaving applications to handle potential anomalies. PostgreSQL defaults to Read Committed. MySQL (InnoDB) defaults to Repeatable Read. Many NoSQL databases don't provide isolation at all.

CockroachDB provides Serializable by default—preventing all anomalies. This is a significant advantage for application developers who don't need to reason about concurrency edge cases.

The Write Skew Problem in Detail:

Write skew is subtle and often causes real-world bugs. Consider a hospital on-call scheduling system:

Rule: At least one doctor must be on-call at all times.
Current state: Dr. Alice is on-call, Dr. Bob is on-call.

Transaction 1 (Alice wants off-call):
  Read: Alice on-call=true, Bob on-call=true
  Check: Someone else is on-call? Yes (Bob)
  Write: Alice on-call=false
  Commit

Transaction 2 (Bob wants off-call): [concurrent]
  Read: Alice on-call=true, Bob on-call=true
  Check: Someone else is on-call? Yes (Alice)
  Write: Bob on-call=false
  Commit

Result: No one is on-call. Rule violated!

Both transactions read consistent data and made correct individual decisions. But the interleaved execution violated the invariant. Serializable isolation prevents this—one transaction would be forced to retry after the other committed.

MVCC is the foundation of CockroachDB's concurrency control. Instead of locking rows during reads (which would block writers), MVCC keeps multiple versions of each row, allowing readers and writers to operate without blocking each other.

How MVCC Works:

Every write creates a new version of the data with a timestamp:

Row: accounts.balance WHERE id = 'alice'

Versions stored:
  @ timestamp 100: balance = 500
  @ timestamp 150: balance = 450  (after $50 withdrawal)
  @ timestamp 200: balance = 550  (after $100 deposit)

When a transaction reads, it reads at its read timestamp—seeing only versions with timestamps less than or equal to that value.

• Transaction at ts=125: sees balance = 500 (version @ 100)
• Transaction at ts=175: sees balance = 450 (version @ 150)
• Transaction at ts=250: sees balance = 550 (version @ 200)

Benefits of MVCC:

1. Non-blocking reads: Readers don't acquire locks; they simply read the appropriate version
2. Consistent snapshots: A transaction sees a consistent view of the database at its read timestamp
3. Time-travel queries: You can query the database as it existed at a past timestamp
4. Efficient rollback: Aborting a transaction just means not committing its versions

MVCC and Storage:

MVCC versions are stored in CockroachDB's underlying storage engine (Pebble, an LSM-tree). The key includes the timestamp, meaning versions are naturally sorted by time. Reading the latest version is a simple seek to the key with the highest timestamp ≤ the read timestamp.

MVCC Overhead:

MVCC isn't free:

• Storage amplification: Multiple versions consume more space
• Garbage collection: Old versions must be cleaned up
• Read amplification: May need to skip over newer versions to find the right one

CockroachDB mitigates these through:

• Aggressive garbage collection of old versions
• Bloom filters and key-prefix optimization in Pebble
• Compaction that removes obsolete versions

MVCC alone provides Snapshot Isolation (SI)—each transaction sees a consistent snapshot. But SI doesn't prevent all anomalies (notably write skew). CockroachDB extends SI with conflict detection to achieve Serializable Snapshot Isolation (SSI).

The SSI Approach:

SSI allows transactions to run optimistically (without blocking), then detects conflicts at commit time. If a conflict would cause a serializability violation, one transaction is aborted and retried.

Conflict Types SSI Detects:

1. Read-Write Conflicts (rw-antidependency)

Transaction B writes data that Transaction A read (and A hasn't committed yet):

A starts @ ts=100: reads accounts.balance
B starts @ ts=150: writes accounts.balance, commits
A tries to commit @ ts=200: ???

If A commits, A would have seen a state that existed before B's write, but A's commit appears after B's. This could cause anomalies. CockroachDB either:

• Pushes A's timestamp forward if A's reads are still valid, or
• Aborts A to retry

2. Write-Read Conflicts (wr-dependency)

Transaction A writes data, Transaction B reads A's write:

A starts @ ts=100: writes accounts.balance = 500
B starts @ ts=150: reads accounts.balance (sees A's write intent)

B must wait for A's outcome:

• If A commits: B reads 500
• If A aborts: B reads the pre-A value

3. Write-Write Conflicts (ww-dependency)

Both transactions write the same key:

A starts @ ts=100: writes accounts.balance = 500
B starts @ ts=150: writes accounts.balance = 600

Only one can win. CockroachDB uses timestamp ordering—the transaction with the lower commit timestamp wins (if it commits). The other must retry.

Write Intents: The Locking Mechanism:

When a transaction writes data, it doesn't immediately commit the value. Instead, it writes a write intent—a provisional value that:

1. Marks the key as being modified by an uncommitted transaction
2. Contains the uncommitted value
3. References the transaction record (for commit/abort status)

Other transactions encountering a write intent must:

• If the intent's transaction is still running: Wait for it to complete
• If the intent's transaction committed: Read the committed value
• If the intent's transaction aborted: Ignore the intent, read the pre-intent value

The Transaction Record:

Each transaction has a transaction record stored in the same keyspace. This record tracks:

• Transaction ID
• Status: PENDING, COMMITTED, ABORTED
• Commit timestamp (if committed)
• List of write intents (ranges that have intents from this transaction)

When a transaction commits, its record is updated atomically. Other transactions checking intent status read this record to determine the outcome.

Timestamps are central to CockroachDB's consistency model. Every transaction has a timestamp that determines:

• What data it can see (MVCC versions ≤ timestamp)
• Its position in the serial order
• Whether it conflicts with other transactions

Hybrid Logical Clocks (HLC):

CockroachDB uses Hybrid Logical Clocks, which combine:

• Physical time: The node's system clock (NTP-synchronized)
• Logical time: A counter that ensures causality when physical time is insufficient

HLC timestamps have the form (physical_time, logical_counter). They're compared lexicographically—physical time first, then logical counter.

Why Not Just System Clocks?

Distributed systems can't rely solely on system clocks because:

1. Clock skew: Different nodes' clocks differ (even with NTP)
2. Clock drift: Clocks diverge over time between synchronizations
3. Clock jumps: NTP corrections can shift clocks backward or forward

HLC handles these by:

• Always moving forward (never going backward)
• Updating based on messages from other nodes
• Ensuring causally-related events are correctly ordered

The Uncertainty Window:

Because node clocks aren't perfectly synchronized, a transaction's timestamp might not reflect the true physical order of events. CockroachDB handles this with uncertainty windows.

When a transaction reads data, it considers values with timestamps in:

[transaction_timestamp - max_offset, transaction_timestamp]

If a value exists in this window, CockroachDB can't be certain whether that value was written before or after the transaction started (due to clock skew). It must either:

1. Wait: Delay until the uncertainty window passes
2. Refresh: Restart the read at a higher timestamp
3. Push: Move the transaction's timestamp forward

Practical Implications:

• max_offset setting: Controls the uncertainty window size (default 500ms, very conservative)
• NTP quality matters: Better clock sync = smaller effective uncertainty = lower latency
• Cloud environments: AWS, GCP, Azure time sync services provide <10ms accuracy

Understanding CockroachDB's transaction model helps you write applications that perform well and handle errors correctly.

Transaction Retries:

CockroachDB automatically retries some transactions internally, but applications must be prepared to handle retry errors:

• Error 40001 (serialization_failure): Transaction conflicted with another; safe to retry
• Error 40003 (statement_completion_unknown): Network issue during commit; check status before retrying

Application-Level Retry Loop:

For operations that might conflict, wrap in a retry loop:

Best Practices for Transactions:

1. Keep Transactions Short

Long-running transactions:

• Hold write intents longer, blocking other transactions
• Are more likely to conflict with concurrent transactions
• Consume resources (memory for transaction state)

Best practice: Transactions should complete in seconds, not minutes.

2. Use SELECT FOR UPDATE for Hot Keys

For frequently-updated data (counters, inventory, balances):

-- Acquire lock immediately, don't wait until UPDATE
SELECT balance FROM accounts WHERE id = 'hot_key' FOR UPDATE;
-- Now other transactions wait at SELECT, not at COMMIT
UPDATE accounts SET balance = balance + 100 WHERE id = 'hot_key';

This trades optimistic concurrency for pessimistic locking on known hot spots.

3. Batch Operations

Instead of separate transactions for each row:

-- BAD: 1000 separate transactions
FOR each item:
    BEGIN; INSERT INTO orders VALUES (...); COMMIT;

-- GOOD: One transaction with batch
BEGIN;
INSERT INTO orders VALUES (...), (...), ..., (...);
COMMIT;

Batching reduces coordination overhead dramatically.

CockroachDB provides Serializable isolation by default, but offers configuration options for specific scenarios.

Default: SERIALIZABLE

All transactions run with serializable isolation unless explicitly changed:

SHOW default_transaction_isolation;
-- Result: serializable

Read Committed Isolation (Experimental)

CockroachDB has experimental support for Read Committed isolation:

SET CLUSTER SETTING sql.txn.read_committed_isolation.enabled = true;

BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- Statements here see Read Committed isolation
COMMIT;

Why use Read Committed?

• Lower contention (no read-set tracking)
• Better performance for some workloads
• Compatibility with applications designed for PostgreSQL's default

Why avoid it?

• Possible anomalies (write skew, phantom reads)
• Application must handle concurrency edge cases
• Loses CockroachDB's key differentiator

Follower Reads: Trading Consistency for Latency

Follower reads allow reading from any replica (not just the leaseholder), accepting bounded staleness:

-- Read data as of ~4.8 seconds ago (guaranteed consistent at that point)
SELECT * FROM products 
AS OF SYSTEM TIME follower_read_timestamp();

-- Read data from a specific time
SELECT * FROM products 
AS OF SYSTEM TIME '-30s';

Follower reads provide:

• Lower latency (read from local replica)
• Reduced load on leaseholder
• Trade: Data is slightly stale (controlled by timestamp)

Savepoints and Nested Transactions:

CockroachDB supports savepoints for partial rollback within transactions:

BEGIN;

INSERT INTO orders (id, total) VALUES (1, 100);
SAVEPOINT before_items;

INSERT INTO order_items (order_id, product_id) VALUES (1, 'PROD_A');
INSERT INTO order_items (order_id, product_id) VALUES (1, 'PROD_B_INVALID');
-- Oops, PROD_B_INVALID doesn't exist

ROLLBACK TO SAVEPOINT before_items;
-- Order insert preserved, items rolled back

INSERT INTO order_items (order_id, product_id) VALUES (1, 'PROD_C');
COMMIT;

Savepoints are useful for:

• Partial error recovery within complex transactions
• Implementing try-catch patterns in stored procedures
• Compatibility with ORMs that use savepoints

We've explored CockroachDB's transaction model in depth. Let's consolidate the key concepts:

What's Next:

Strong consistency is only part of the picture. In the next page, we'll explore Automatic Load Balancing—how CockroachDB distributes data across nodes, manages leaseholders, and rebalances the cluster as data grows and access patterns change. This is the operational magic that makes CockroachDB self-managing.