- How transactions work in CockroachDB, including serializability and transaction retries
- How applications interact with CockroachDB
How transactions work in CockroachDB
CockroachDB is designed to make your data scalable and consistent. All stored records are replicated across a distributed deployment of database instances, and all database transactions committed in CockroachDB satisfy ACID properties. To guarantee that database operations are atomic (the “A” of the ACID properties), CockroachDB executes all statements in the context of an atomic database transaction. If a transaction succeeds, all data mutations are applied together simultaneously from the perspective of operations outside of the transaction. If any part of a transaction fails, the entire transaction is aborted, and the database is left unchanged. Managing transactions is an important part of CockroachDB application development. When creating your application’s persistence layer, you must understand how CockroachDB interacts with your application framework’s transaction management system. You should also have some knowledge of CockroachDB’s transaction syntax. We go into more detail about transaction management in Manage Transactions.Serializability and transaction contention
By default, CockroachDB usesSERIALIZABLE transaction isolation (the “I” of ACID semantics). If transactions are executed concurrently, the final state of the database will appear as if the transactions were executed serially. SERIALIZABLE isolation, the strictest level of isolation, provides the highest level of data consistency and protects against concurrency anomalies.
To guarantee data consistency, CockroachDB locks the data targeted by an open transaction. If a separate transaction attempts to modify data that are locked by an open transaction, the newest transaction will not succeed, as committing it could result in incorrect data. This scenario is called transaction contention, and should be avoided when possible. For a more detailed explanation of transaction contention, and tips on how to avoid it, see Transaction contention.
Transaction retries
In some cases, transaction contention is unavoidable. If a transaction fails due to contention, CockroachDB will automatically retry the transaction. If the transaction isSERIALIZABLE and cannot automatically be retried without allowing serialization anomalies, CockroachDB will return a transaction retry error to the client.
Most official CockroachDB client libraries include a transaction-retrying wrapper function to make writing your persistence layer easier. If your framework’s client library does not include a retry wrapper, you will need to write transaction retry logic in your application. We go into more detail about transaction retries later in the guide, in Retry Transactions.
Read Committed isolation
CockroachDB can be configured to execute transactions atREAD COMMITTED instead of SERIALIZABLE isolation. READ COMMITTED permits some concurrency anomalies in exchange for minimizing transaction aborts and removing the need for client-side retries. Depending on your workload requirements, this may be desirable. For more information, see Read Committed Transactions.

