What are 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

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

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 / 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 — 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]);

// 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") }
}

// 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

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:

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

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

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

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 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.