ACID or A.C.I.D
What is ACID?
ACID stands for atomicity, consistency, isolation, and durability. These are a set of characteristics that are desirable for database transactions. Together, they guarantee that transactions and all data stored in the database remains valid even in the event of errors or power failures. These characteristics are extremely important for any database.
The Four ACID Properties: Atomicity, Consistency, Isolation, Durability
Atomicity
The “all or nothing” principle. Each transaction must be treated as a single, indivisible unit (even if processing the transaction requires multiple steps). In other words, every step of the transaction must complete successfully or the entire transaction will fail and no change will be written to the database. This is desirable because without atomicity, a transaction that’s interrupted while processing may only write a portion of the changes it’s supposed to make, which could leave the database in an inconsistent state.
Example: A bank transfer. Imagine if it only partially went through, then the bank balances of both the recipient and the sender would be unclear and inconsistent. Multiply this singular incomplete transaction and you have a large-scale problem.
Consistency
No transaction can violate the integrity of the database – all transactions must leave the database in a valid state. Consensus algorithms like Raft and Paxos can help ensure data consistency across distributed systems.
Example: Inventory management. You might have brick-and-mortar stores as well as an online presence. It’s important to ensure that the inventory listed in your database is correct at all times across both physical locations and online stock so that customers don’t pay for an item that is sold out.
Isolation
Any concurrently-processed transactions (i.e. transactions happening at the same time) have the same effect on the database as if they were executed sequentially (i.e. one after another). Perfect isolation between transactions—serializable isolation—creates some restrictions on concurrent data processing. So many databases adopt lower levels of isolation or allow applications to choose from various isolation levels.
Example: Imagine person A is transferring money to person B at the same time that person B is transferring money to person C. It’s important that the bank balance for all three people is accurate and up-to-date based on the amounts transferred in both cases.
See what happens when transactions are not properly isolated:
Durability
Once committed, the transaction remains committed even in the case of hardware failure, power outage, etc.
Example: With organizations experiencing 86 outages each year, handling failures is part of running a business today. In large-scale systems, you should expect that something will fail eventually (network partition, regional outage, disk stall, cloud outage, etc.). In the event that there is a failure, you need the reassurance that your data has not been corrupted or lost.
If you’re interested in learning more about why durability matters today, and why databases should be benchmarked according to how they perform when everything fails, check out the video below explaining CockroachDB’s new database benchmarking methodology “Performance under Adversity”:
Why ACID transactions matter
ACID transactions ultimately give your users the confidence that the data they are seeing, using, and analyzing is accurate, up-to-date, and safe. Particularly for distributed databases and distributed transactions, it is important that all of the data viewed is consistent wherever and whenever a user retrieves that data, even when transactions span multiple geographic locations. For example, a company like Amazon, which has warehouses all over the world, needs to ensure that their inventory is accurate and up-to-date at all times for all of their global consumers.
In addition, while many emerging regulations do not explicitly require ACID-compliant transactions, the properties enforced by the ACID framework can support the outcomes desired by these regulatory bodies. For example, in the case of GDPR which focuses on data privacy, consistency and durability can support accurate and timely corrections and deletion of personal data. In the case of PCI-DSS and payment processing, data integrity is also critical, and all 4 ACID properties help to prevent data corruption and loss.
ACID compliance in databases
Not all databases are built to support ACID transactions. For example, NoSQL databases are often associated with speed, scalability, and schema flexibility — but historically, they did not guarantee full ACID compliance. Instead, following the BASE model, which stands for basically available, soft state, and eventually consistent. This tradeoff was intentional, favoring eventual consistency and high availability over strict transaction guarantees.
Distributed SQL databases, like CockroachDB, offer the scale and speed of NoSQL databases, while providing the reliability, resilience, and ACID transactions of traditional SQL and relational databases.
ACID transactions with CockroachDB
CockroachDB, the first commercially available distributed SQL database, was built to be ACID compliant. Since its founding, the engineering team has continued to develop a set of integrated architectural mechanisms designed to be always-on, resilient, and performant at scale. Below are just a few of the features available today and how they relate to the four ACID properties.
Atomicity in CockroachDB
All SQL statements in CockroachDB are treated as transactions, including single statements ("autocommit mode"). If any part of a transaction fails, the entire transaction is aborted, and the database is left unchanged. Successful transactions commit all changes as a unit.
Consistency in CockroachDB
CockroachDB uses the Raft consensus protocol to ensure data consistency between replicas. Before any write is committed, a quorum of replicas must agree on the change, guaranteeing that only valid, conflict-free changes are applied.
The transaction layer coordinates distributed transactions using an atomic commit protocol called Parallel Commits, allowing transactions (including those that span multiple nodes or tables) to be committed only when all necessary conditions are met.
Isolation in CockroachDB
CockroachDB supports SERIALIZABLE and READ COMMITTED isolation levels, with SERIALIZABLE as the default — the highest standard defined by SQL. This level requires that transactions appear to execute one at a time, preventing phenomena such as dirty reads or lost updates.
Concurrency is controlled using mechanisms like latches, lock tables (for write and read locks), and timestamp caches, which collectively ensure transactions are isolated and that conflicts are correctly resolved.
Multi-version concurrency control (MVCC) enables transactions to operate on consistent snapshots of data, ensuring proper ordering and retrying of conflicting operations.
Durability in CockroachDB
Data is not considered committed until it has been replicated and persisted on disk by a quorum of nodes, leveraging Raft’s consensus and log replication. In case of a node or disk failure, data can be restored from other replicas’ Raft logs or Raft snapshots, ensuring no committed transaction is ever lost.
In the case of transient disk stalls, commonly seen in cloud storage, CockroachDB also supports write-ahead log (WAL) failover. WAL failover uses a secondary disk as a fail-to for the write-ahead log so that when the primary disk stalls, failover to the secondary occurs and solves the problem of write latency in the presence of a disk stall.
Distributed and Self-Healing Guarantees
CockroachDB is designed for self-healing: if a node or region fails, the system automatically rebalances data as needed, so that surviving nodes can continue serving requests while maintaining ACID properties.
High availability and rapid recovery are further reinforced through backup systems, automatic failover, and distributed consensus, which together deliver robust transactional guarantees even in the face of widespread failures.
In summary, CockroachDB’s combination of distributed, consensus-driven replication, sophisticated transaction coordination, concurrency control mechanisms, and careful conflict management allows it to offer strict ACID compliance — even for globally distributed workloads.
ACID Transaction FAQ
What does ACID stand for in databases?
ACID stands for Atomicity, Consistency, Isolation, and Durability. These are the four key properties that ensure reliable, safe, and consistent database transactions.
Why are ACID transactions important?
ACID transactions prevent data loss, corruption, or inconsistency. They ensure that even in the event of system crashes, power failures, or concurrent user activity, the database remains in a valid and predictable state.
What is an example of an ACID transaction?
A classic example is a bank transfer. Money is withdrawn from one account and deposited into another. ACID ensures that either both actions succeed (atomicity), or neither happens. The balance stays consistent, even under concurrent access or failure.
Do all databases support ACID transactions?
No. Relational databases like PostgreSQL, MySQL (with InnoDB), and SQL Server are fully ACID-compliant. However, many NoSQL databases may relax one or more of the ACID properties in favor of performance or scalability, often using the BASE model instead.
Can distributed databases provide ACID compliance?
Yes, modern distributed SQL databases can support ACID transactions using consensus protocols (like Raft or Paxos), distributed transaction logs, and coordination layers that ensure consistency across nodes.
