---
term: 'ACID Transactions'
seoTitle: 'What are ACID Transactions? Properties & Examples'
headline: 'What are ACID Transactions?'
slug: acid-transactions
category: database
shortDefinition: 'An ACID transaction is a group of database operations that commits as one unit — atomic, consistent, isolated, and durable.'
relatedTerms:
  - database-queries
  - database-index
  - nosql-vs-sql
  - crud-operations
contrastsWith:
  - nosql-vs-sql
faq:
  - question: 'What does ACID stand for?'
    answer: 'Atomicity, Consistency, Isolation, Durability — the four guarantees a database transaction must give for data to stay correct through errors, crashes, and concurrent users. Jim Gray defined the core properties in 1981; Theo Härder and Andreas Reuter coined the acronym in their 1983 paper on transaction-oriented recovery.'
  - question: 'What is an ACID transaction in simple terms?'
    answer: 'A group of reads and writes executed as one all-or-nothing unit. Either every operation commits and becomes permanent, or every operation rolls back as if nothing happened. The canonical example is a money transfer: debit one account, credit another — a crash between the two must never leave the money debited but not credited.'
  - question: 'What are isolation levels?'
    answer: 'The dial that trades performance for protection when transactions run concurrently. The SQL standard defines four — read uncommitted, read committed, repeatable read, serializable — each preventing more anomalies (dirty reads, non-repeatable reads, phantoms) at more cost. In practice most modern engines default to snapshot-style isolation via MVCC, where readers see a consistent snapshot and never block writers.'
  - question: 'What is the difference between ACID and BASE?'
    answer: 'Two answers to the cost of correctness. ACID pays in coordination to guarantee every transaction sees and leaves a valid state. BASE — Basically Available, Soft state, Eventually consistent — pays in temporary staleness to stay available and scale horizontally. Neither is superior; they price consistency differently, and real systems mix them per workload.'
  - question: 'Is consistency in ACID the same as consistency in the CAP theorem?'
    answer: 'No — and conflating them is the most common confusion on this topic. ACID consistency means every transaction preserves the declared rules: constraints hold, invariants survive. CAP consistency means every node in a distributed system sees the same data at the same time. A single-node database can be fully ACID while CAP has nothing to say about it.'
  - question: 'Are NoSQL databases ACID compliant?'
    answer: 'Increasingly, with fine print. Document databases have always made single-document writes atomic — which, combined with embedding related data, covers most app needs. Multi-document ACID transactions arrived in MongoDB 4.0 (2018) with snapshot isolation, at a real performance cost. The old "NoSQL means no transactions" claim is now simply outdated; the design preference for modeling around single-document atomicity is not.'
  - question: 'How do databases actually implement ACID?'
    answer: 'Three mechanisms carry the load: undo information makes rollback possible (atomicity); write-ahead logging — changes recorded to a durable log before being applied — survives crashes (durability); and either locking or MVCC keeps concurrent transactions out of each other''s way (isolation). Consistency is the outcome: constraints checked inside the protection of the other three.'
  - question: 'When is eventual consistency good enough?'
    answer: 'When a brief window of staleness costs nothing: like counts, view counters, activity feeds, analytics, caches, product recommendations. When it is not: money, inventory that can oversell, seat and ticket booking, anything regulated. The engineering skill is not choosing a side but routing each write to the guarantee it actually needs.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'ACID (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/ACID'
  - name: 'The Transaction Concept — Jim Gray (1981)'
    url: 'https://jimgray.azurewebsites.net/papers/thetransactionconcept.pdf'
  - name: 'Principles of Transaction-Oriented Database Recovery — Härder & Reuter (1983)'
    url: 'https://dl.acm.org/doi/10.1145/289.291'
  - name: 'MongoDB ACID transactions guide'
    url: 'https://www.mongodb.com/resources/basics/databases/acid-transactions'
cta:
  title: 'Correctness without the ceremony'
  text: 'Back4app gives you the atomicity apps actually need: atomic counters and array operations, all-or-nothing batch saves, and Cloud Code for multi-step workflows validated server-side — on a managed document database you never operate.'
  linkText: 'Start building free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-26'
translationKey: acid-transactions
---

**An ACID transaction is a group of database operations that commits as one unit — atomic, consistent, isolated, and durable.** The idea predates the acronym: Jim Gray defined the guarantees in 1981, Härder and Reuter named them ACID in 1983, and forty years later it remains the contract that lets you move money in software without occasionally inventing or destroying some.

## Key takeaways

| Question | Answer |
| --- | --- |
| The four letters | Atomic (all-or-nothing) · Consistent (rules hold) · Isolated (no interference) · Durable (survives crashes) |
| Canonical example | The bank transfer: debit + credit commit together or not at all |
| The dial | Isolation levels — performance traded against read anomalies |
| The rival | BASE / eventual consistency — availability traded against staleness |
| The modern reality | Document databases do ACID too; the fine print is *scope* |

## How ACID Transactions Work in SQL (Bank-Transfer Example)

```sql
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 'alice';
UPDATE accounts SET balance = balance + 100 WHERE id = 'bob';

-- Crash or error between the two updates? The engine rolls back:
-- ROLLBACK;  →  both changes vanish; money cannot evaporate

COMMIT;       -- or both become permanent, atomically, durably
```

Application code meets the same guarantees in smaller packages — atomic field operations that end the read-modify-write race, and batches that commit together:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// Atomicity where apps actually need it
counter.increment('sold', 1);        // atomic single-field update — no
await counter.save();                // read-modify-write race possible

// All-or-nothing batch: both rows commit, or neither does
await Parse.Object.saveAll([debitEntry, creditEntry], { transaction: true });
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// Atomicity where apps actually need it
counter.setIncrement('sold', 1);     // atomic single-field update — no
await counter.save();                // read-modify-write race possible

// Batches group writes; atomic counters remove the classic race
await ParseObject.saveAll([debitEntry, creditEntry]);
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// Atomicity where apps actually need it
var updated = counter
updated.sold = (updated.sold ?? 0) + 1
// Prefer the atomic operation over read-modify-write:
let op = counter.operation.increment("sold", by: 1)
op.save { result in
  if case .success = result { print("atomic increment committed") }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// Atomicity where apps actually need it
counter.increment("sold")            // atomic single-field update — no
counter.saveInBackground()           // read-modify-write race possible

// Batches group writes; atomic counters remove the classic race
ParseObject.saveAllInBackground(listOf(debitEntry, creditEntry))
```

## The Transaction Lifecycle: BEGIN, COMMIT, and ROLLBACK

```mermaid
flowchart LR
  accTitle: Transaction lifecycle
  accDescr: A transaction begins, performs operations against a working state, and either commits — making all changes permanent — or rolls back on any failure, restoring the previous valid state.
  B["BEGIN"] --> O["Operations<br/>reads + writes, isolated"]
  O -->|"all succeed"| C["COMMIT<br/>permanent, durable"]
  O -->|"any failure"| R["ROLLBACK<br/>as if nothing happened"]
```

The four properties, each by what breaks without it: **atomicity** — without it, partial writes (the debited-but-never-credited transfer). **Consistency** — without it, committed states that violate your own rules (negative stock, orphaned references). **Isolation** — without it, concurrent transactions read each other's half-finished work. **Durability** — without it, "committed" data that a crash quietly unwrites. Under the hood, three mechanisms deliver them: undo logs for rollback, write-ahead logging for crash survival, and locking or MVCC for concurrency.

## Isolation levels vs. read anomalies

The matrix the SERP never assembles — which level stops which anomaly:

| Level | Dirty read | Non-repeatable read | Phantom read | Cost |
| --- | --- | --- | --- | --- |
| Read uncommitted | possible | possible | possible | lowest |
| Read committed | prevented | possible | possible | low |
| Repeatable read | prevented | prevented | possible | medium |
| Serializable | prevented | prevented | prevented | highest |

Translations: a *dirty read* sees uncommitted work; a *non-repeatable read* gets different answers asking twice; a *phantom* sees rows appear mid-transaction. Most modern engines default to MVCC-based snapshot behavior — each transaction reads a consistent snapshot while writers proceed — which is why "readers don't block writers" became the norm rather than the exception.

## ACID vs. BASE — and the consistency homonym

| Dimension | ACID | BASE |
| --- | --- | --- |
| Optimizes for | Correctness per transaction | Availability at scale |
| Consistency | Immediate, rule-preserving | Eventual |
| Natural home | Money, inventory, bookings | Feeds, counters, caches |
| Scaling posture | Coordination-bound | Horizontal by design |
| Failure mode | Slower under contention | Temporarily stale reads |

One disambiguation carries this whole comparison: **ACID's C and CAP's C are different words wearing the same letter.** ACID consistency means each transaction preserves your declared rules. CAP consistency means all nodes agree right now. A single-node database is fully ACID without CAP entering the room; a distributed system chooses its CAP trade-off *and* its transactional guarantees separately.

## Who guarantees what

| Engine family | ACID story |
| --- | --- |
| PostgreSQL | Full ACID, MVCC, serializable available |
| MySQL | Full ACID **with InnoDB** — engine choice matters |
| SQLite | Full ACID, single-writer, WAL mode |
| MongoDB | Single-document atomicity always; multi-document transactions since 4.0 (2018), snapshot isolation |
| Distributed SQL engines | ACID via consensus replication — serializable at network prices |
| Wide-column / eventual stores | Tunable, partial — BASE by design |

Distributed transactions deserve their honest footnote: **two-phase commit** buys cross-node atomicity at the price of latency and a blocking coordinator, which is why microservice architectures increasingly prefer **sagas** — sequences of local transactions with compensating rollbacks, trading immediate consistency for availability. If a workflow genuinely cannot tolerate compensation, that's evidence it belongs inside one database, not across several.

## Common use cases

- **Money movement.** Transfers, payouts, ledgers — the canonical case and still the clearest.
- **Inventory and booking.** Decrement stock and confirm the order together, or watch two customers buy the last seat.
- **Multi-row invariants.** Order + line items, account + audit entry — records that are only valid born together.
- **Counters done right.** Atomic increments — ACID's smallest useful dose — end the read-modify-write race without full transactions.
- **The eventual-consistency complement.** Feeds, likes, analytics: explicitly routed *away* from transactional cost, on purpose.

## Must it be ACID? A decision matrix

| Demand full transactions when… | Eventual consistency is fine when… |
| --- | --- |
| Money or ownership changes hands | A stale count costs nothing |
| Partial writes create invalid states | Each write is independently valid |
| Regulators will ask for the invariant | The data is derived and rebuildable |
| Two rows must agree, always | Convergence-later is acceptable UX |
| Overselling is a lawsuit | Overcounting is a shrug |

The craft is per-write routing: the checkout uses transactions, the view counter uses an atomic increment, the feed tolerates a second of drift — one application, three price points for consistency.

## Limitations and trade-offs

- **Coordination is the cost center.** Locks contend, WAL syncs hit disk, serializable retries abort — correctness has a throughput bill, which is the entire reason BASE exists.
- **Isolation levels are a loaded default.** Most engines don't default to serializable; know your level, or anomalies you thought impossible are merely unlikely.
- **Long transactions are a smell.** Holding locks across user think-time or network calls turns guarantees into contention; keep transactions short and decisive.
- **Distributed ACID is expensive by nature.** Consensus rounds per commit — pay it where invariants demand, not everywhere by reflex.
- **ACID can't validate your rules for you.** Consistency preserves *declared* constraints; business rules never encoded are faithfully not enforced.

## Transactions on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Its transactional toolkit matches how apps actually consume ACID: every single-object write is atomic on the underlying document engine, [atomic increments and array operations](https://www.mongodb.com/resources/basics/databases/acid-transactions) end the classic counter races (the code tabs above), batch saves group writes, and multi-step invariants belong in Cloud Code — validated and executed server-side, where a beforeSave trigger can refuse any write that would break the rules. The decision matrix comes built in: cheap atomicity by default, full coordination where you ask for it.