ACID-Transaktionen sind Datenbank-Änderungen, die vier Zusagen einhalten: Atomarität (alles oder nichts), Konsistenz (Regeln bleiben gültig), Isolation (parallele Zugriffe stören sich nicht) und Dauerhaftigkeit (einmal gespeichert, bleibt gespeichert). Auf Englisch stehen die Anfangsbuchstaben für Atomicity, Consistency, Isolation, Durability. Sie sorgen dafür, dass eine Änderung entweder ganz oder gar nicht in der Datenbank landet, auch bei Abstürzen oder gleichzeitigen Zugriffen.
Was ist eine ACID-Transaktion?
Eine Transaktion (englisch für „Vorgang") bündelt mehrere Einzelschritte zu einem gemeinsamen Vorgang, den die Datenbank nur komplett oder gar nicht ausführt. Das Standardbeispiel ist die Überweisung, bei der Abbuchung und Gutschrift zusammengehören. Das Kürzel ACID geht auf Theo Härder und Andreas Reuter (1983) zurück; gebräuchlich sind auch die Bezeichnungen ACID-Prinzip und ACID-Eigenschaften, in der deutschen Literatur zudem AKID (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit). Die vier Zusagen im Einzelnen:
- Atomarität: Eine Transaktion wird vollständig ausgeführt oder vollständig zurückgerollt. Teilergebnisse erreichen die Datenbank nie.
- Konsistenz: Jede Transaktion überführt die Datenbank von einem gültigen Zustand in den nächsten. Definierte Integritätsregeln bleiben gewahrt.
- Isolation: Parallel laufende Transaktionen beeinflussen sich nicht. Jede verhält sich so, als liefe sie allein auf dem System.
- Dauerhaftigkeit: Nach erfolgreichem Commit überleben die Änderungen auch einen Absturz oder Stromausfall.
Relationale Datenbanksysteme setzen diese Garantien seit Jahrzehnten über Write-Ahead-Logs, Sperrverfahren oder Multi-Version Concurrency Control (MVCC) um. ACID ist dort die technische Basis für Datenintegrität in operativen Systemen, von der Buchung bis zur Bestandsführung.
Im Data-Umfeld hat der Begriff eine zweite Karriere gemacht. Klassische Data Lakes legen Daten als Dateien im Objekt-Storage ab und bieten dafür keine Transaktionsgarantien: Abgebrochene Jobs hinterlassen Teilzustände, Leser sehen Zwischenstände. Table Formats wie [Delta Lake](/insights/lakehouse/delta-lake/) und Apache Iceberg führen ein Transaktionslog über die Parquet-Dateien einer Tabelle und bringen damit ACID-Garantien in den Data Lake. Auf demselben Mechanismus bauen Funktionen wie Time Travel auf. Genau diese Transaktionsgarantien machen den Data Lake zur tragfähigen Analytics-Plattform und gelten als technisches Fundament des [Data Lakehouse](/insights/lakehouse/).
Abgrenzung: ACID vs. BASE und ACID im Lakehouse
Das häufigste Gegenmodell ist BASE (Basically Available, Soft State, Eventually Consistent), das viele NoSQL-Systeme prägt. BASE priorisiert Verfügbarkeit und nimmt in Kauf, dass Replikate erst zeitversetzt denselben Stand erreichen (Eventual Consistency). ACID garantiert zu jedem Zeitpunkt einen gültigen Zustand; BASE konvergiert über die Zeit dorthin.
Die zweite typische Verwechslung betrifft ACID in OLTP-Datenbanken und ACID auf Tabellen-Ebene im Lakehouse. Die Garantien sind gleich, Mechanismus und Einsatzprofil unterscheiden sich deutlich:
| ACID in OLTP-Datenbanken | ACID im Lakehouse (Delta Lake, Iceberg) | |
|---|---|---|
| Mechanismus | Write-Ahead-Log, Locking oder MVCC in der Datenbank-Engine | Transaktionslog über Dateien im Objekt-Storage |
| Typische Last | viele kleine, parallele Schreibzugriffe | große Batch- und Streaming-Writes |
| Einsatz | operative Systeme (Buchungen, Bestellungen) | analytische Tabellen, ETL- und Streaming-Pipelines |
Für hochfrequente Einzelzeilen-Updates bleibt eine OLTP-Datenbank das passende Werkzeug. Das Lakehouse nutzt ACID, um analytische Tabellen bei parallelen Lese- und Schreibzugriffen konsistent zu halten.
Beispiel: abgebrochener Ladejob
Das klassische Lehrbuchbeispiel ist die Banküberweisung: Abbuchung und Gutschrift bilden eine Transaktion, ein Dritter sieht das Geld nie auf beiden Konten gleichzeitig. Im Analytics-Alltag sieht das relevante Szenario anders aus: Ein nächtlicher Ladejob schreibt 40 Millionen Zeilen in eine Tabelle und bricht nach der Hälfte ab. Ohne Transaktionsgarantien liegen danach unvollständige Dateien im Data Lake, und nachgelagerte Reports rechnen mit Teilmengen. Schreibt der Job in eine Delta-Lake-Tabelle, wird der Commit erst nach Abschluss ins Transaktionslog eingetragen. Bricht der Lauf vorher ab, sehen Leser weiterhin den letzten gültigen Tabellenstand, und der Job kann ohne Aufräumarbeiten neu starten.
ACID-Transaktionen im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.