Transaction Isolation Selector

When to Use

You have a database with concurrent transaction access and need to choose the right isolation level — or you suspect an existing isolation level is inadequate for your concurrency patterns.

This skill applies when any of the following are true:

• You are building a new service and need to decide what isolation level to configure
• You have a bug that appears nondeterministically and involves concurrent reads and writes
• You are migrating to a new database and need to verify the isolation guarantees are equivalent
• Your application touches multiple rows or tables within a single transaction
• Your business logic reads a value and then conditionally writes based on it (the write skew pattern)

Critical default: Most databases do NOT default to serializable isolation. Oracle 11g does not implement true serializable at all — its "serializable" level is actually snapshot isolation. PostgreSQL defaults to read committed. MySQL InnoDB defaults to repeatable read (which is snapshot isolation in MySQL's implementation). If you have not explicitly set your isolation level, you are running at a weaker level than serializable, and some anomalies are possible.

Related skills:

• concurrency-anomaly-detector — if you already have a bug and need to identify the anomaly type
• consistency-model-selector — for distributed system consistency guarantees (linearizability, eventual consistency)