---
title: "Isolation level"
description: "An isolation level defines how much one transaction's in-progress changes are visible to other concurrently running transactions, trading off consistency against concurrency."
canonical: "https://motherduck.com/glossary/isolation-level/"
related:
  - title: "Database Concepts | MotherDuck Docs"
    url: "https://motherduck.com/docs/concepts/database-concepts/"
  - title: "DuckLake Architecture Deep Dive"
    url: "https://motherduck.com/blog/ducklake-architecture-deep-dive/"
  - title: "What's New in DuckDB 1.5! | MotherDuck"
    url: "https://motherduck.com/videos/whats-new-duckdb-15/"
---

# Isolation level

> An isolation level defines how much one transaction's in-progress changes are visible to other concurrently running transactions, trading off consistency against concurrency.

## Overview

Isolation is one of the four ACID properties, but in practice it isn't all-or-nothing — SQL databases expose a spectrum of isolation levels that trade strict consistency for higher concurrency. The SQL standard defines four levels, each preventing a different set of anomalies.

## Standard Isolation Levels

- **Read Uncommitted** — transactions can see other transactions' uncommitted changes ("dirty reads"). Rarely used in practice.
- **Read Committed** — a transaction only ever sees data that has been committed, but a value it reads twice may change between reads ("non-repeatable read").
- **Repeatable Read** — a transaction sees a consistent snapshot for values it has already read, but new rows matching a filter may appear on a re-run ("phantom read").
- **Serializable** — transactions behave as if they ran one at a time in some serial order; the strongest and most expensive level.

Stricter isolation levels prevent more anomalies but generally require more locking or more conflict aborts, reducing throughput under contention.

## DuckDB's Isolation Level

DuckDB provides **snapshot isolation**: every transaction sees a consistent snapshot of the database as of the moment it started, and concurrent writers don't block each other. DuckDB doesn't expose a `SET TRANSACTION ISOLATION LEVEL` knob — snapshot isolation is the fixed behavior. Because DuckDB uses optimistic concurrency control rather than locking, a write-write conflict (two transactions modifying the same rows) doesn't wait; instead, whichever transaction commits second fails with a conflict error and must be retried.