Erfahre, wie ACID-Garantien Datenbankdesign und Anwendungsverhalten beeinflussen. Entdecke Atomarität, Konsistenz, Isolation, Dauerhaftigkeit, Abwägungen und Praxisbeispiele.
Wenn Sie für Lebensmittel bezahlen, einen Flug buchen oder Geld zwischen Konten verschieben, erwarten Sie ein eindeutiges Ergebnis: entweder es hat funktioniert oder nicht. Datenbanken wollen dieselbe Gewissheit bieten — selbst wenn viele Nutzer gleichzeitig im System sind, Server abstürzen oder Netzwerke schwächeln.
Eine Transaktion ist eine einzelne Arbeitseinheit, die die Datenbank als ein „Paket“ behandelt. Sie kann mehrere Schritte enthalten — Lagerbestand verringern, Bestellung anlegen, Karte belasten und eine Quittung schreiben — soll aber als eine zusammenhängende Aktion funktionieren.
Wenn ein Schritt fehlschlägt, sollte das System lieber auf einen sicheren Zustand zurückrollen, statt einen halb fertigen Zustand zu hinterlassen.
Partielle Updates sind nicht nur technische Fehler; sie werden zu Support-Fällen und finanziellen Risiken. Zum Beispiel:
Solche Fehler sind schwer zu debuggen, weil alles „meistens korrekt“ aussieht, aber die Zahlen nicht stimmen.
ACID steht für vier Garantien, die viele Datenbanken für Transaktionen bieten können:
Es ist keine spezifische Datenbankmarke oder ein einzelner Schalter; es ist ein Versprechen über das Verhalten.
Stärkere Garantien bedeuten meist mehr Arbeit für die Datenbank: zusätzliche Koordination, Warten auf Sperren, Versionsverfolgung und Schreiben in Logs. Das kann Durchsatz verringern oder Latenz unter hoher Last erhöhen. Das Ziel ist nicht „überall maximale ACID“, sondern Garantien zu wählen, die zu Ihren echten Geschäftsrisiken passen.
Atomarität bedeutet, dass eine Transaktion als eine einzige Arbeitseinheit behandelt wird: sie wird entweder vollständig ausgeführt oder hat keinerlei Effekt. Sie sehen niemals ein „halb aktualisiertes" Ergebnis in der Datenbank.
Stellen Sie sich vor, Sie transferieren 50 $ von Alice zu Bob. Unter der Haube beinhaltet das typischerweise mindestens zwei Änderungen:
Mit Atomarität gelingen beide Änderungen zusammen oder keine von beiden. Wenn das System nicht beide sicher durchführen kann, muss es keine ausführen. Das verhindert den Albtraum, dass Alice belastet wird, Bob aber das Geld nicht erhält (oder Bob erhält es, ohne dass Alice belastet wurde).
Datenbanken geben Transaktionen zwei Ausgänge:
Ein hilfreiches Modell ist „Entwurf vs. Veröffentlichen“. Solange die Transaktion läuft, sind die Änderungen vorläufig. Nur ein Commit veröffentlicht sie.
Atomarität ist wichtig, weil Fehler normal sind:
Wenn eines davon passiert, bevor der Commit abgeschlossen ist, sorgt Atomarität dafür, dass die Datenbank zurückrollen kann, damit keine Teilarbeit in echte Salden einfließt.
Atomarität schützt den Datenbankzustand, aber Ihre Anwendung muss weiterhin mit Unsicherheit umgehen — besonders wenn ein Netzwerkabbruch unklar lässt, ob ein Commit stattgefunden hat.
Zwei praktische Ergänzungen:
Zusammen helfen atomare Transaktionen und idempotente Retries, sowohl partielle Updates als auch versehentliche Doppelbelastungen zu vermeiden.
Konsistenz in ACID bedeutet nicht „die Daten sehen sinnvoll aus“ oder „alle Replikate stimmen überein“. Es bedeutet, dass jede Transaktion die Datenbank von einem gültigen Zustand in einen anderen gültigen Zustand überführt — gemäß den Regeln, die Sie festlegen.
Eine Datenbank kann Daten nur relativ zu expliziten Constraints, Triggern und Invarianten konsistent halten, die beschreiben, was „gültig“ für Ihr System ist. ACID erfindet diese Regeln nicht; es setzt sie während Transaktionen durch.
Gängige Beispiele sind:
order.customer_id muss auf einen existierenden Kunden zeigen.Wenn diese Regeln gesetzt sind, wird die Datenbank jede Transaktion ablehnen, die sie verletzen würde — so entstehen keine „halbgültigen“ Daten.
App-Level-Validierung ist wichtig, reicht aber allein nicht aus.
Ein klassisches Ausfallmuster ist: die App prüft „E‑Mail ist verfügbar“ und führt dann ein Insert aus. Unter Nebenläufigkeit können zwei Requests die Prüfung gleichzeitig bestehen. Ein Unique-Constraint in der Datenbank garantiert, dass nur ein Insert erfolgreich ist.
Wenn Sie „keine negativen Salden“ als Constraint kodieren (oder es zuverlässig innerhalb einer Transaktion durchsetzen), muss jede Überweisung, die ein Konto überziehen würde, als Ganzes fehlschlagen. Wenn Sie diese Regel nirgendwo kodieren, kann ACID sie nicht schützen — weil es nichts gibt, das durchgesetzt werden könnte.
Konsistenz bedeutet letztlich: machen Sie die Regeln explizit, und lassen Sie Transaktionen dafür sorgen, dass sie nie gebrochen werden.
Isolation sorgt dafür, dass Transaktionen sich nicht gegenseitig in die Quere kommen. Während eine Transaktion läuft, sollen andere Transaktionen keine halb abgeschlossenen Arbeiten sehen oder sie aus Versehen überschreiben. Das Ziel ist einfach: jede Transaktion soll sich so verhalten, als ob sie allein läuft, auch wenn viele Nutzer gleichzeitig aktiv sind.
Echte Systeme sind beschäftigt: Kunden bestellen, Support-Mitarbeiter aktualisieren Profile, Hintergrundjobs gleichen Zahlungen ab — gleichzeitig. Diese Aktionen überschneiden sich zeitlich und betreffen oft dieselben Zeilen (Kontostand, Lagerbestand oder Buchungsplatz).
Ohne Isolation wird Timing Teil Ihrer Geschäftslogik. Ein „Bestand abziehen“-Update kann mit einem anderen Checkout konkurrieren, oder ein Report liest Daten mitten in einer Änderung und zeigt Zahlen, die nie in einem stabilen Zustand existiert haben.
Volle „so tun, als wäre man allein“ Isolation kann teuer sein. Sie kann Durchsatz reduzieren, Wartezeiten (Sperren) erhöhen oder zu Transaktionsretries führen. Viele Workflows brauchen nicht den strengsten Schutz — für Analytics etwa sind leicht veraltete Daten oft akzeptabel.
Deshalb bieten Datenbanken konfigurierbare Isolationsstufen: Sie wählen, welches Nebenläufigkeitsrisiko Sie im Tausch gegen bessere Performance und weniger Konflikte akzeptieren.
Wenn die Isolation für Ihre Workload zu schwach ist, stoßen Sie auf klassische Anomalien:
Diese Fehlermodi zu verstehen erleichtert die Auswahl einer Isolationsstufe, die zu Ihren Produktversprechen passt.
Isolation bestimmt, was andere Transaktionen sehen dürfen, während Ihre noch läuft. Ist sie zu schwach, können Anomalien auftreten — technisch möglich, für Nutzer aber überraschend.
Dirty Read tritt auf, wenn Sie Daten lesen, die eine andere Transaktion geschrieben, aber noch nicht committed hat.
Szenario: Alex überweist 500 $, der Saldo fällt vorübergehend auf 200 $, und Sie lesen diese 200 $, bevor Alex’ Transfer später fehlschlägt und zurückgerollt wird.
Nutzerfolge: Ein Kunde sieht ein fälschlich niedriges Guthaben, eine Betrugsregel feuert fälschlich, oder ein Support-Mitarbeiter gibt die falsche Auskunft.
Non-repeatable Read bedeutet, Sie lesen dieselbe Zeile zweimal und erhalten unterschiedliche Werte, weil eine andere Transaktion dazwischen committed hat.
Szenario: Sie laden einen Bestellbetrag (49,00 $) und sehen bei einem erneuten Abruf kurz darauf 54,00 $, weil eine Rabattposition entfernt wurde.
Nutzerfolge: „Mein Gesamtbetrag hat sich während des Bezahlens geändert“ — Misstrauen oder abgebrochene Warenkörbe.
Phantom Read ähnelt non-repeatable read, betrifft aber eine Zeilenmenge: Eine zweite Abfrage liefert zusätzliche (oder fehlende) Zeilen, weil eine andere Transaktion passende Datensätze eingefügt/gelöscht hat.
Szenario: Eine Hotelsuche zeigt „3 Zimmer verfügbar“, beim Buchen prüft das System erneut und findet keine mehr, weil neue Reservierungen hinzugekommen sind.
Nutzerfolge: Doppelte Buchungsversuche, inkonsistente Verfügbarkeitsanzeigen oder Überverkauf.
Lost Update entsteht, wenn zwei Transaktionen denselben Wert lesen und beide Updates zurückschreiben, wobei das spätere das frühere überschreibt.
Szenario: Zwei Admins bearbeiten denselben Produktpreis. Beide starten bei 10 $; einer speichert 12 $, der andere speichert zuletzt 11 $.
Nutzerfolge: Eine Änderung verschwindet; Summen und Reports sind falsch.
Write Skew passiert, wenn zwei Transaktionen jeweils eine Änderung vornehmen, die einzeln gültig ist, zusammen aber eine Regel verletzen.
Szenario: Regel: „Mindestens ein diensthabender Arzt muss geplant sein.“ Zwei Ärzte setzen unabhängig voneinander sich selbst als dienstfrei, nachdem sie gesehen haben, dass der andere noch eingetragen ist.
Nutzerfolge: Am Ende gibt es keine Abdeckung mehr, obwohl jede Transaktion für sich die Prüfung bestanden hat.
Stärkere Isolation reduziert Anomalien, kann aber Wartezeiten, Retries und Kosten unter hoher Nebenläufigkeit erhöhen. Viele Systeme wählen schwächere Isolation für leselastige Analytics und strengere Einstellungen für Geldbewegungen, Buchungen und andere korrektheitskritische Abläufe.
Isolation definiert, was Ihre Transaktion „sehen“ darf, während andere laufen. Datenbanken stellen das über Isolationsstufen bereit: höhere Stufen reduzieren überraschendes Verhalten, können aber Durchsatz oder Wartezeiten kosten.
Teams wählen oft Read Committed als Default für nutzerorientierte Apps: gute Performance und „keine dirty reads“ entspricht den meisten Erwartungen.
Nutzen Sie Repeatable Read, wenn Sie innerhalb einer Transaktion stabile Ergebnisse brauchen (z. B. Rechnungserstellung) und etwas Overhead tolerieren.
Nutzen Sie Serializable, wenn Korrektheit wichtiger ist als Nebenläufigkeit (z. B. komplexe Invarianten wie „niemals Überverkauf“) oder wenn Sie Race-Conditions im App-Code schwer analysieren können.
Read Uncommitted ist in OLTP-Systemen selten; es wird manchmal für Monitoring oder ungefähre Reports genutzt, wo falsche Reads akzeptabel sind.
Die Namen sind standardisiert, aber genaue Garantien unterscheiden sich je nach Datenbank-Engine (und manchmal per Konfiguration). Prüfen Sie die Dokumentation Ihrer DB und testen die für Ihr Geschäft relevanten Anomalien.
Dauerhaftigkeit bedeutet, dass einmal committete Transaktionen ihre Ergebnisse über einen Absturz hinweg behalten — Stromausfall, Prozessneustart oder plötzlicher Reboot. Wenn Ihre App einem Kunden „Zahlung erfolgreich“ meldet, ist Dauerhaftigkeit das Versprechen, dass die Datenbank diese Tatsache nach einem Ausfall nicht „vergisst".
Die meisten relationalen Datenbanken erreichen Dauerhaftigkeit mit Write-Ahead Logging (WAL). Grob gesagt schreibt die Datenbank eine sequentielle „Quittung“ der Änderungen in ein Log auf die Festplatte, bevor sie die Transaktion als committed betrachtet. Nach einem Crash kann die DB das Log beim Start replayen, um die committeten Änderungen wiederherzustellen.
Um die Wiederherstellungszeit begrenzt zu halten, erstellen Datenbanken auch Checkpoints. Ein Checkpoint ist ein Moment, in dem die DB sicherstellt, dass genügend der jüngsten Änderungen in die Hauptdatendateien geschrieben wurden, sodass die Recovery nicht eine unbeschränkte Log-Historie abspielen muss.
Dauerhaftigkeit ist kein Ein/Aus-Schalter; sie hängt davon ab, wie aggressiv die DB Daten auf stabilem Speicher erzwingt.
fsync) bevor sie Commit bestätigt. Das ist sicherer, kann aber Latenz hinzufügen.Auch die zugrunde liegende Hardware spielt eine Rolle: SSDs, RAID-Controller mit Schreibcache und Cloud-Volumes verhalten sich bei Ausfällen unterschiedlich.
Backups und Replikation helfen bei Wiederherstellung oder Reduzierung der Ausfallzeit, sind aber nicht dasselbe wie Dauerhaftigkeit. Eine Transaktion kann auf dem Primary dauerhaft sein, auch wenn sie noch nicht an eine Replica übertragen wurde. Backups sind typischerweise point-in-time Schnappschüsse und keine Commit-für-Commit-Garantien.
Wenn Sie BEGIN und später COMMIT ausführen, koordiniert die Datenbank viele Komponenten: wer welche Zeilen lesen darf, wer sie ändern darf und was passiert, wenn zwei Leute dieselbe Zeile ändern wollen.
Eine wesentliche „unter der Haube“ Entscheidung ist, wie Konflikte gehandhabt werden:
Viele Systeme mischen beide Ideen, abhängig von Workload und Isolationsstufe.
Moderne Datenbanken verwenden oft MVCC (Multi-Version Concurrency Control): statt nur eine Kopie einer Zeile zu halten, verwaltet die DB mehrere Versionen.
Das ist ein Hauptgrund, warum manche DBs viele Reads und Writes gleichzeitig mit weniger Blocking verarbeiten können — obwohl Write/Write-Konflikte weiterhin gelöst werden müssen.
Sperren können zu Deadlocks führen: Transaktion A wartet auf eine Sperre von B, während B auf eine Sperre von A wartet.
Datenbanken erkennen typischerweise den Zyklus und brechen eine Transaktion ab (ein „Deadlock-Victim“) und geben einen Fehler zurück, sodass die Anwendung einen Retry versuchen kann.
Wenn ACID-Durchsetzung Reibung erzeugt, sehen Sie oft:
Diese Symptome deuten oft darauf hin, Transaktionsgröße, Indexierung oder die passende Isolation/Sperrstrategie zu überdenken.
ACID-Garantien sind nicht nur Theorie — sie beeinflussen, wie Sie APIs, Hintergrundjobs und sogar UI-Flows gestalten. Die Kernidee: entscheiden Sie, welche Schritte zusammen erfolgreich sein müssen, und packen Sie nur diese Schritte in eine Transaktion.
Eine gute transaktionale API bildet gewöhnlich eine einzelne Geschäftsaktion ab, auch wenn sie mehrere Tabellen berührt. Ein /checkout-Endpunkt könnte z. B. eine Bestellung anlegen, Inventar reservieren und eine Zahlungsabsicht aufzeichnen. Diese Datenbankschreibvorgänge sollten typischerweise in einer Transaktion liegen, sodass sie zusammen committen (oder zusammen zurückrollen), wenn eine Validierung fehlschlägt.
Ein gängiges Muster ist:
So erhalten Sie Atomarität und Konsistenz, vermeiden aber langsame, fragile Transaktionen.
Wo Sie Transaktionsgrenzen ziehen, hängt davon ab, was „eine Arbeitseinheit“ bedeutet:
ACID hilft, aber Ihre Anwendung muss Fehler korrekt behandeln:
Vermeiden Sie lange Transaktionen, aufrufe externer APIs innerhalb einer Transaktion und Nutzersprechzeiten innerhalb einer Transaktion (z. B. „Warenkorb sperren, Nutzer um Bestätigung bitten"). Diese erhöhen Contentions und machen Isolationskonflikte wahrscheinlicher.
Wenn Sie schnell ein transaktionales System bauen, ist das größte Risiko selten, „ACID nicht zu kennen“ — es ist vielmehr, eine Geschäftsaktion über mehrere Endpunkte, Jobs oder Tabellen zu verteilen, ohne klare Transaktionsgrenzen.
Plattformen wie Koder.ai können Ihnen helfen, schneller zu werden und trotzdem um ACID herum zu designen: Sie können einen Workflow beschreiben (z. B. „Checkout mit Inventarreservierung und Zahlungsabsicht“), eine React-UI plus Go + PostgreSQL Backend generieren und mit Snapshots/Rollbacks iterieren, falls Schema oder Transaktionsgrenzen geändert werden müssen. Die Datenbank erzwingt weiterhin die Garantien; der Wert liegt im schnelleren Weg von einem korrekten Entwurf zu einer funktionierenden Implementierung.
Eine einzelne Datenbank liefert normalerweise ACID-Garantien innerhalb einer Transaktionsgrenze. Sobald Sie Arbeit über mehrere Services (und oft mehrere Datenbanken) verteilen, sind diese Garantien schwerer zu halten — und teurer, wenn Sie sie durchsetzen.
Strikte Konsistenz bedeutet, jeder Read sieht die „aktuellste committe Wahrheit“. Hohe Verfügbarkeit bedeutet, das System antwortet weiterhin, selbst wenn Teile langsam oder unerreichbar sind.
In einer Multi-Service-Architektur kann ein temporäres Netzwerkproblem eine Wahl erzwingen: warten/fehlschlagen, bis alle Teilnehmer zustimmen (mehr Konsistenz, weniger Verfügbarkeit), oder akzeptieren, dass Services kurz inkonsistent sind (mehr Verfügbarkeit, weniger Konsistenz). Keines davon ist immer richtig — es hängt davon ab, welche Fehler Ihr Business tolerieren kann.
Verteilte Transaktionen erfordern Koordination über Grenzen, die Sie nicht vollständig kontrollieren: Netzwerkverzögerungen, Retries, Timeouts, Service-Abstürze und partielle Fehler.
Selbst wenn jeder Service korrekt arbeitet, kann das Netzwerk Mehrdeutigkeiten schaffen: Hat der Zahlungsservice committed, aber der Bestellservice die Bestätigung nie erhalten? Um das sicher zu lösen, nutzen Systeme Koordinationsprotokolle (z. B. Two-Phase Commit), die langsam sein, Verfügbarkeit bei Fehlern reduzieren und operative Komplexität erhöhen können.
Sagas teilen einen Workflow in Schritte, die jeweils lokal committed werden. Schlägt ein späterer Schritt fehl, werden frühere Schritte mit Kompensationsaktionen rückgängig gemacht (z. B. Rückerstattung einer Zahlung).
Outbox/Inbox-Pattern machen das Publizieren und Konsumieren von Events zuverlässig. Ein Service schreibt die Geschäftsdaten und einen „zu publishenden Event“-Datensatz in derselben lokalen Transaktion (Outbox). Konsumenten protokollieren verarbeitete Nachrichten-IDs (Inbox), um Retries ohne Duplikate zu handhaben.
Eventual Consistency akzeptiert kurze Zeitfenster, in denen Daten zwischen Services abweichen, und hat einen klaren Plan zur Nachbearbeitung.
Lockern Sie Garantien, wenn:
Kontrollieren Sie Risiken, indem Sie Invarianten definieren (was niemals verletzt werden darf), idempotente Operationen gestalten, Timeouts und Retries mit Backoff verwenden und Drift überwachen (hängende Sagas, wiederholte Kompensationen, wachsende Outbox-Tabellen). Für wirklich kritische Invarianten (z. B. „nie ein Konto überziehen") halten Sie diese möglichst innerhalb eines einzelnen Services und einer einzigen Datenbanktransaktion.
Eine Transaktion kann im Unit-Test „korrekt“ sein und dennoch unter realem Traffic, Neustarts und Nebenläufigkeit versagen. Nutzen Sie diese Checkliste, damit ACID-Garantien mit dem Verhalten Ihres Systems in Produktion übereinstimmen.
Beginnen Sie damit, aufzuschreiben, was immer wahr sein muss (Ihre Dateninvarianten). Beispiele: „Kontostand wird nie negativ“, „Bestelltotal = Summe der Positionen“, „Bestand darf nicht unter Null fallen“, „eine Zahlung ist genau einer Bestellung zugeordnet“. Betrachten Sie diese als Produktregeln, nicht als DB-Trivia.
Entscheiden Sie dann, was innerhalb einer Transaktion sein muss und was verzögert werden kann.
Halten Sie Transaktionen klein: weniger Zeilen berühren, weniger Arbeit tun (keine externen API-Aufrufe) und schnell committen.
Machen Sie Nebenläufigkeit zu einer erstklassigen Testdimension.
Wenn Sie Retries unterstützen, fügen Sie einen expliziten Idempotenz-Schlüssel hinzu und testen Sie „Anfrage wiederholt nach Erfolg".
Beobachten Sie Indikatoren, dass Ihre Garantien teuer oder fragil werden:
Alarmieren Sie auf Trends, nicht nur auf Peaks, und verknüpfen Sie Metriken mit den Endpunkten oder Jobs, die sie verursachen.
Verwenden Sie die schwächste Isolation, die Ihre Invarianten noch schützt; setzen Sie sie nicht standardmäßig auf Maximum. Wenn Sie strikte Korrektheit für einen kleinen kritischen Abschnitt benötigen (Geldbewegung, Bestandsreduzierung), begrenzen Sie die Transaktion auf genau diesen Abschnitt und halten Sie alles andere außen vor.
ACID ist ein Set von Transaktionsgarantien, die Datenbanken helfen, sich unter Ausfällen und Nebenläufigkeit vorhersehbar zu verhalten:
Eine Transaktion ist eine einzige „Arbeitseinheit“, die die Datenbank als ein Paket behandelt. Selbst wenn sie mehrere SQL-Anweisungen ausführt (z. B. Bestellung anlegen, Bestand verringern, Zahlungsabsicht speichern), hat sie nur zwei mögliche Ausgänge:
Weil partielle Updates reale Widersprüche erzeugen, die später teuer zu beheben sind. Beispiele:
ACID (insbesondere Atomarität + Konsistenz) verhindert, dass solche „halb fertigen“ Zustände als Wahrheit sichtbar werden.
Atomarität sorgt dafür, dass die Datenbank niemals einen „halb abgeschlossenen“ Zustand preisgibt. Wenn etwas vor dem Commit schiefgeht — App-Absturz, Netzwerkunterbrechung, DB-Neustart — wird die Transaktion zurückgerollt, damit frühere Schritte nicht in den persistenten Zustand gelangen.
In der Praxis macht Atomarität mehrstufige Änderungen (z. B. eine Überweisung, die zwei Salden aktualisiert) sicher.
Man kann nicht immer wissen, ob ein Commit stattgefunden hat, wenn der Client die Antwort verliert (z. B. Netzwerk-Timeout unmittelbar nach Commit). Kombinieren Sie ACID-Transaktionen mit:
Das verhindert sowohl partielle Updates als auch versehentliche Doppelbelastungen/-schreibungen.
Bei ACID bedeutet „Konsistenz“, dass die Datenbank den Zustand von einem gültigen Zustand in einen anderen gültigen Zustand überführt — gemäß den Regeln, die Sie definieren (Constraints, Foreign Keys, Checks).
Wenn Sie eine Regel nicht explizit kodieren (z. B. „Saldo darf nicht negativ sein“), kann ACID sie nicht automatisch durchsetzen. Die Datenbank braucht eindeutige Invarianten, um zu schützen.
App-Validierung verbessert die Nutzererfahrung und kann komplexe Regeln prüfen, sie versagt aber bei Nebenläufigkeit (z. B. zwei Anfragen prüfen gleichzeitig, ob eine E‑Mail frei ist).
Datenbank-Constraints sind der endgültige Gatekeeper:
Nutzen Sie beides: früh in der App validieren, in der DB endgültig erzwingen.
Isolation steuert, was Ihre Transaktion beobachten darf, während andere laufen. Schwache Isolation kann Anomalien erzeugen wie:
Isolationsstufen erlauben Ihnen, Performance gegen Schutz vor diesen Anomalien abzuwägen.
Ein praxisüblicher Ausgangspunkt ist Read Committed für viele OLTP-Anwendungen: verhindert Dirty Reads und liefert gute Performance. Höhere Stufen wählen, wenn nötig:
Prüfen Sie immer das Verhalten in Ihrem konkreten Datenbanksystem, denn Details variieren.
Dauerhaftigkeit bedeutet: wenn die Datenbank einen Commit bestätigt, sollte die Änderung Abstürze überleben. Üblicherweise wird das über Write-Ahead Logging (WAL) und Checkpoints erreicht.
Was Dauerhaftigkeit schwächen kann:
Backups und Replikation helfen bei Recovery und Verfügbarkeit, sind aber nicht dasselbe wie Dauerhaftigkeit pro Commit.