---
term: 'ACID-Transaktionen'
seoTitle: 'Was sind ACID-Transaktionen? Eigenschaften und Beispiele'
headline: 'Was sind ACID-Transaktionen?'
slug: acid-transaktionen
category: database
shortDefinition: 'Eine ACID-Transaktion ist eine Gruppe von Datenbankoperationen, die als eine Einheit festgeschrieben wird – atomar, konsistent, isoliert und dauerhaft.'
relatedTerms:
  - database-queries
  - database-index
  - nosql-vs-sql
  - crud-operations
contrastsWith:
  - nosql-vs-sql
faq:
  - question: 'Wofür steht ACID?'
    answer: 'Für Atomicity, Consistency, Isolation, Durability – auf Deutsch Atomarität, Konsistenz, Isolation und Dauerhaftigkeit: die vier Garantien, die eine Datenbanktransaktion geben muss, damit Daten trotz Fehlern, Abstürzen und gleichzeitiger Nutzer korrekt bleiben. Jim Gray definierte die Kerneigenschaften 1981; Theo Härder und Andreas Reuter prägten das Akronym 1983 in ihrem Artikel über transaktionsorientierte Wiederherstellung.'
  - question: 'Was ist eine ACID-Transaktion, einfach erklärt?'
    answer: 'Eine Gruppe von Lese- und Schreibvorgängen, die als eine Alles-oder-nichts-Einheit ausgeführt wird. Entweder wird jede Operation festgeschrieben und dauerhaft, oder jede Operation wird zurückgerollt, als wäre nichts geschehen. Das klassische Beispiel ist eine Überweisung: ein Konto belasten, ein anderes gutschreiben – ein Absturz zwischen beiden Schritten darf das Geld nie belastet, aber nicht gutgeschrieben zurücklassen.'
  - question: 'Was sind Isolationsstufen?'
    answer: 'Der Regler, der bei gleichzeitig laufenden Transaktionen Performance gegen Schutz abwägt. Der SQL-Standard definiert vier – Read Uncommitted, Read Committed, Repeatable Read, Serializable –, von denen jede mehr Anomalien verhindert (Dirty Reads, nicht wiederholbare Lesevorgänge, Phantome) und dafür mehr kostet. In der Praxis verwenden die meisten modernen Engines standardmäßig eine Snapshot-Isolation über MVCC, bei der Leser einen konsistenten Snapshot sehen und Schreiber nie blockieren.'
  - question: 'Was ist der Unterschied zwischen ACID und BASE?'
    answer: 'Zwei Antworten auf die Kosten der Korrektheit. ACID zahlt mit Koordination, um zu garantieren, dass jede Transaktion einen gültigen Zustand vorfindet und hinterlässt. BASE – Basically Available, Soft State, Eventually Consistent – zahlt mit vorübergehend veralteten Daten, um verfügbar zu bleiben und horizontal zu skalieren. Keines ist überlegen; sie bepreisen Konsistenz unterschiedlich, und reale Systeme mischen beide je nach Workload.'
  - question: 'Ist Konsistenz bei ACID dasselbe wie Konsistenz im CAP-Theorem?'
    answer: 'Nein – und die Verwechslung ist das häufigste Missverständnis bei diesem Thema. ACID-Konsistenz bedeutet, dass jede Transaktion die deklarierten Regeln wahrt: Constraints gelten, Invarianten bleiben erhalten. CAP-Konsistenz bedeutet, dass jeder Knoten eines verteilten Systems zur selben Zeit dieselben Daten sieht. Eine Datenbank auf einem einzigen Knoten kann vollständig ACID-konform sein, ohne dass CAP dazu irgendetwas aussagt.'
  - question: 'Sind NoSQL-Datenbanken ACID-konform?'
    answer: 'Zunehmend – mit Kleingedrucktem. Dokumentdatenbanken schreiben einzelne Dokumente seit jeher atomar, was zusammen mit eingebetteten verwandten Daten die meisten Anforderungen von Apps abdeckt. ACID-Transaktionen über mehrere Dokumente kamen mit MongoDB 4.0 (2018) samt Snapshot-Isolation – zu spürbaren Performancekosten. Die alte Behauptung "NoSQL heißt keine Transaktionen" ist schlicht veraltet; die Designvorliebe, Daten um die Atomarität einzelner Dokumente herum zu modellieren, dagegen nicht.'
  - question: 'Wie setzen Datenbanken ACID tatsächlich um?'
    answer: 'Drei Mechanismen tragen die Last: Undo-Informationen machen den Rollback möglich (Atomarität); Write-Ahead-Logging – Änderungen werden in ein dauerhaftes Log geschrieben, bevor sie angewendet werden – übersteht Abstürze (Dauerhaftigkeit); und Sperren oder MVCC halten gleichzeitige Transaktionen voneinander fern (Isolation). Konsistenz ist das Ergebnis: Constraints, die im Schutz der anderen drei geprüft werden.'
  - question: 'Wann reicht Eventual Consistency aus?'
    answer: 'Wenn ein kurzes Fenster veralteter Daten nichts kostet: Like-Zähler, Aufrufzähler, Aktivitätsfeeds, Analytics, Caches, Produktempfehlungen. Wenn nicht: Geld, Lagerbestände, die überverkauft werden können, Sitzplatz- und Ticketbuchungen, alles Regulierte. Die Ingenieurskunst liegt nicht darin, sich für eine Seite zu entscheiden, sondern jeden Schreibvorgang zu der Garantie zu leiten, die er tatsächlich braucht.'
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: 'Korrektheit ohne Zeremoniell'
  text: 'Back4app bietet die Atomarität, die Apps tatsächlich brauchen: atomare Zähler und Array-Operationen, Batch-Speichervorgänge nach dem Alles-oder-nichts-Prinzip und Cloud Code für mehrstufige, serverseitig validierte Workflows – auf einer verwalteten Dokumentdatenbank, die Sie nie selbst betreiben.'
  linkText: 'Kostenlos starten'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-22'
translationKey: acid-transactions
---

**Eine ACID-Transaktion ist eine Gruppe von Datenbankoperationen, die als eine Einheit festgeschrieben wird – atomar, konsistent, isoliert und dauerhaft.** Die Idee ist älter als das Akronym: Jim Gray definierte die Garantien 1981, Härder und Reuter nannten sie 1983 ACID, und vierzig Jahre später ist sie noch immer der Vertrag, der es erlaubt, Geld in Software zu bewegen, ohne gelegentlich welches zu erfinden oder zu vernichten.

## Das Wichtigste in Kürze

| Frage | Antwort |
| --- | --- |
| Die vier Buchstaben | Atomar (alles oder nichts) · Konsistent (Regeln gelten) · Isoliert (keine Störung) · Dauerhaft (übersteht Abstürze) |
| Klassisches Beispiel | Die Überweisung: Belastung und Gutschrift werden gemeinsam festgeschrieben oder gar nicht |
| Der Regler | Isolationsstufen – Performance gegen Leseanomalien abgewogen |
| Der Gegenspieler | BASE / Eventual Consistency – Verfügbarkeit gegen veraltete Daten abgewogen |
| Die heutige Realität | Auch Dokumentdatenbanken beherrschen ACID; das Kleingedruckte ist der *Geltungsbereich* |

## Wie ACID-Transaktionen in SQL funktionieren (Beispiel Überweisung)

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

-- Absturz oder Fehler zwischen den beiden Updates? Die Engine rollt zurück:
-- ROLLBACK;  →  beide Änderungen verschwinden; kein Geld geht verloren

COMMIT;       -- oder beide werden gültig: atomar und dauerhaft
```

Anwendungscode begegnet denselben Garantien in kleineren Portionen – atomare Feldoperationen, die das Wettrennen beim Lesen-Ändern-Schreiben beenden, und Batches, die gemeinsam festgeschrieben werden:

**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))
```

## Der Lebenszyklus einer Transaktion: BEGIN, COMMIT und ROLLBACK

```mermaid
flowchart LR
  accTitle: Lebenszyklus einer Transaktion
  accDescr: Eine Transaktion beginnt, führt Operationen auf einem Arbeitszustand aus und wird entweder festgeschrieben – alle Änderungen werden dauerhaft – oder bei jedem Fehler zurückgerollt, wodurch der vorherige gültige Zustand wiederhergestellt wird.
  B["BEGIN"] --> O["Operationen<br/>Lesen + Schreiben, isoliert"]
  O -->|"alle erfolgreich"| C["COMMIT<br/>festgeschrieben, dauerhaft"]
  O -->|"ein Fehler"| R["ROLLBACK<br/>als wäre nichts geschehen"]
```

Die vier Eigenschaften, jeweils beschrieben durch das, was ohne sie kaputtgeht: **Atomarität** – ohne sie gibt es halbe Schreibvorgänge (die belastete, aber nie gutgeschriebene Überweisung). **Konsistenz** – ohne sie gibt es festgeschriebene Zustände, die Ihre eigenen Regeln verletzen (negativer Lagerbestand, verwaiste Referenzen). **Isolation** – ohne sie lesen gleichzeitige Transaktionen die halbfertige Arbeit der anderen. **Dauerhaftigkeit** – ohne sie gibt es "festgeschriebene" Daten, die ein Absturz stillschweigend wieder löscht. Unter der Haube liefern drei Mechanismen diese Eigenschaften: Undo-Logs für den Rollback, Write-Ahead-Logging für das Überstehen von Abstürzen und Sperren oder MVCC für die Nebenläufigkeit.

## Isolationsstufen vs. Leseanomalien

Die Übersicht, die man sonst selten an einem Ort findet – welche Stufe welche Anomalie verhindert:

| Stufe | Dirty Read | Non-Repeatable Read | Phantom Read | Kosten |
| --- | --- | --- | --- | --- |
| Read Uncommitted | möglich | möglich | möglich | am niedrigsten |
| Read Committed | verhindert | möglich | möglich | niedrig |
| Repeatable Read | verhindert | verhindert | möglich | mittel |
| Serializable | verhindert | verhindert | verhindert | am höchsten |

Zur Einordnung: Ein *Dirty Read* sieht noch nicht festgeschriebene Arbeit; ein *Non-Repeatable Read* erhält auf dieselbe Frage zweimal unterschiedliche Antworten; ein *Phantom* sieht mitten in der Transaktion neue Zeilen auftauchen. Die meisten modernen Engines arbeiten standardmäßig mit MVCC-basierten Snapshots – jede Transaktion liest einen konsistenten Snapshot, während Schreiber weiterarbeiten –, weshalb "Leser blockieren keine Schreiber" zur Regel statt zur Ausnahme geworden ist.

## ACID vs. BASE – und das Homonym Konsistenz

| Dimension | ACID | BASE |
| --- | --- | --- |
| Optimiert auf | Korrektheit pro Transaktion | Verfügbarkeit bei großer Last |
| Konsistenz | Sofort, regelwahrend | Eventual (letztendlich) |
| Natürliches Einsatzgebiet | Geld, Lagerbestände, Buchungen | Feeds, Zähler, Caches |
| Skalierungsverhalten | Durch Koordination begrenzt | Von Grund auf horizontal |
| Fehlerbild | Langsamer bei Konkurrenz um Sperren | Vorübergehend veraltete Lesezugriffe |

Eine Klarstellung trägt diesen ganzen Vergleich: **Das C in ACID und das C in CAP sind verschiedene Wörter mit demselben Buchstaben.** ACID-Konsistenz bedeutet, dass jede Transaktion Ihre deklarierten Regeln wahrt. CAP-Konsistenz bedeutet, dass sich alle Knoten genau jetzt einig sind. Eine Datenbank auf einem einzigen Knoten ist vollständig ACID-konform, ohne dass CAP überhaupt ins Spiel kommt; ein verteiltes System wählt seinen CAP-Trade-off *und* seine Transaktionsgarantien getrennt voneinander.

## Wer was garantiert

| Engine-Familie | ACID-Status |
| --- | --- |
| PostgreSQL | Volles ACID, MVCC, Serializable verfügbar |
| MySQL | Volles ACID **mit InnoDB** – die Wahl der Storage Engine zählt |
| SQLite | Volles ACID, ein einzelner Schreiber, WAL-Modus |
| MongoDB | Atomarität einzelner Dokumente immer; Transaktionen über mehrere Dokumente seit 4.0 (2018), Snapshot-Isolation |
| Verteilte SQL-Engines | ACID über Konsens-Replikation – Serializable zu Netzwerkpreisen |
| Wide-Column- / Eventual-Stores | Einstellbar, teilweise – BASE von Grund auf |

Verteilte Transaktionen verdienen eine ehrliche Fußnote: **Two-Phase Commit** (Zwei-Phasen-Commit) erkauft Atomarität über Knoten hinweg mit Latenz und einem blockierenden Koordinator. Deshalb setzen Microservice-Architekturen zunehmend auf **Sagas** – Folgen lokaler Transaktionen mit kompensierenden Rollbacks, die sofortige Konsistenz gegen Verfügbarkeit tauschen. Wenn ein Workflow Kompensation wirklich nicht verträgt, ist das ein Beleg dafür, dass er in eine einzige Datenbank gehört, nicht über mehrere verteilt.

## Typische Anwendungsfälle

- **Geldbewegungen.** Überweisungen, Auszahlungen, Hauptbücher – der klassische Fall und noch immer der eindeutigste.
- **Lagerbestand und Buchungen.** Bestand verringern und Bestellung bestätigen, beides gemeinsam – sonst kaufen zwei Kunden den letzten Platz.
- **Invarianten über mehrere Zeilen.** Bestellung + Positionen, Konto + Audit-Eintrag – Datensätze, die nur gültig sind, wenn sie gemeinsam entstehen.
- **Zähler, richtig gemacht.** Atomare Inkremente – die kleinste nützliche Dosis ACID – beenden das Wettrennen beim Lesen-Ändern-Schreiben ohne vollständige Transaktionen.
- **Die Ergänzung durch Eventual Consistency.** Feeds, Likes, Analytics: bewusst *weg* von den Kosten der Transaktionen geleitet.

## Muss es ACID sein? Eine Entscheidungsmatrix

| Bestehen Sie auf vollständigen Transaktionen, wenn … | Eventual Consistency genügt, wenn … |
| --- | --- |
| Geld oder Eigentum den Besitzer wechselt | Ein veralteter Zähler nichts kostet |
| Halbe Schreibvorgänge ungültige Zustände erzeugen | Jeder Schreibvorgang für sich gültig ist |
| Aufsichtsbehörden nach der Invariante fragen werden | Die Daten abgeleitet und rekonstruierbar sind |
| Zwei Zeilen immer übereinstimmen müssen | Spätere Konvergenz für die UX akzeptabel ist |
| Überverkauf eine Klage bedeutet | Überzählen ein Achselzucken ist |

Die Kunst liegt im Routing pro Schreibvorgang: Der Checkout nutzt Transaktionen, der Aufrufzähler ein atomares Inkrement, der Feed verträgt eine Sekunde Abweichung – eine Anwendung, drei Preisstufen für Konsistenz.

## Grenzen und Trade-offs

- **Koordination ist der Kostentreiber.** Sperren konkurrieren, WAL-Syncs gehen auf die Platte, Serializable-Wiederholungen brechen ab – Korrektheit kostet Durchsatz, und genau deshalb gibt es BASE.
- **Isolationsstufen sind ein folgenreicher Standard.** Die meisten Engines verwenden standardmäßig nicht Serializable; kennen Sie Ihre Stufe, sonst sind Anomalien, die Sie für unmöglich hielten, bloß unwahrscheinlich.
- **Lange Transaktionen sind ein Warnsignal.** Wer Sperren über die Bedenkzeit von Nutzern oder über Netzwerkaufrufe hinweg hält, macht aus Garantien Konkurrenz um Sperren; halten Sie Transaktionen kurz und entschieden.
- **Verteiltes ACID ist von Natur aus teuer.** Konsensrunden bei jedem Commit – zahlen Sie das dort, wo Invarianten es verlangen, nicht reflexhaft überall.
- **ACID kann Ihre Regeln nicht für Sie validieren.** Konsistenz wahrt *deklarierte* Constraints; Geschäftsregeln, die nie codiert wurden, werden zuverlässig nicht durchgesetzt.

## ACID-Transaktionen mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Ihr Transaktionswerkzeug entspricht der Art, wie Apps ACID tatsächlich nutzen: Jeder Schreibvorgang auf ein einzelnes Objekt ist in der zugrunde liegenden Dokument-Engine atomar, [atomare Inkremente und Array-Operationen](https://www.mongodb.com/resources/basics/databases/acid-transactions) beenden die klassischen Wettrennen bei Zählern (siehe Code-Tabs oben), Batch-Speichervorgänge bündeln Schreibvorgänge, und mehrstufige Invarianten gehören in Cloud Code – serverseitig validiert und ausgeführt, wo ein beforeSave-Trigger jeden Schreibvorgang ablehnen kann, der die Regeln verletzen würde. Die Entscheidungsmatrix ist eingebaut: günstige Atomarität als Standard, volle Koordination dort, wo Sie sie anfordern.