Eine Checkliste zur Datenbankbewertung sollte die Regeln, auf die Ihr Geschäft angewiesen ist, mit Nachweisen verknüpfen: Kann die Datenbank diese Regeln einhalten? Prüfen Sie Client-Kompatibilität, SQL-Verhalten, nebenläufige Transaktionen und Dauerhaftigkeit getrennt. Halten Sie den genauen Build, die Einstellungen, beobachtete Ergebnisse und offene Fragen fest, bevor Sie der Datenbank führende Datenbestände anvertrauen.

[Jepsens ParticleDB-Bericht vom 31. Oktober](https://jepsen.io/analyses/particledb-1.1.4) zeigt, wie aktuell diese Unterscheidung ist. Die von Orkes finanzierte Untersuchung umfasste Einzelknoten-Installationen der Versionen 1.1.4 bis 1.1.18.11.rc-22 und beschrieb 96 Fehler. Im letzten getesteten Build schienen alle bis auf zehn behoben zu sein. Laut Jepsen meldet Orkes weitere Korrekturen für 1.1.19-rc.13; [Orkes' Beitrag vom 30. Oktober](https://orkes.io/blog/particledb-database-built-for-ai-agents) nennt dagegen 1.1.19 als Stand, ab dem die Fehler behoben seien. Diese neueren Builds lagen außerhalb des veröffentlichten Testumfangs von Jepsen.

Für Ihre Bewertung zählt, was ein Ergebnis für Ihre Anwendung tatsächlich belegt. Das folgende Vorgehen ist ein Vorschlag, kein von uns durchgeführter Datenbanktest.

## Beginnen Sie mit einer fachlichen Regel

Notieren Sie eine Bedingung, die auch bei überlappenden Anfragen oder einem Prozessabbruch gelten muss. Diese Ausgangsanforderung wird häufig als Invariante bezeichnet.

Bei einem Buchungsprodukt dürfen die bestätigten Reservierungen die Kapazität nicht überschreiten. In einem Kontenbuch darf bei einer Umbuchung nicht nur eine der beiden Buchungen festgeschrieben werden. Wählen Sie Regeln aus Ihrer Anwendung. Legen Sie auch fest, was Nutzer nach einem Erfolg oder Fehler sehen dürfen.

Halten Sie fest, wo jede Regel durchgesetzt wird: durch eine Integritätsbedingung der Datenbank, eine Transaktion, Anwendungscode oder ein externes System. Eine Datenbank kann keine Regel einhalten, die Ihre Implementierung nirgends ausdrückt. So können Sie auch einen Fehler untersuchen, ohne ihn sofort der Speicher-Engine zuzuschreiben.

## Erfassen Sie die Nachweise je Ebene

Planen Sie die Bewertung anhand dieser Tabelle. Jede Zeile beantwortet eine andere Frage. Ein erfolgreiches Ergebnis in einer Zeile lässt die übrigen offen.

| Ebene | Zu erhebende Nachweise | Was damit noch nicht belegt ist |
| --- | --- | --- |
| Protokoll- und API-Kompatibilität | Tatsächlich genutzte Treiber- und Verbindungspool-Operationen, Prepared Statements, zurückgegebene Datentypen und Fehlerbehandlung | Korrekte SQL-Ergebnisse oder Transaktionsgarantien |
| SQL und Integritätsbedingungen | Repräsentative Abfragen und absichtlich ungültige Schreibvorgänge samt erwarteten Ergebnissen und Zeitpunkt der Bedingungsprüfung | Verhalten bei überlappenden Transaktionen |
| Nebenläufige Transaktionen | Überlappende Operationen, geprüft anhand der dokumentierten Isolationsstufe und Ihrer fachlichen Regel | Erhalt bestätigter Schreibvorgänge nach einem Ausfall |
| Dauerhaftigkeit und Wiederherstellung | Welche bestätigten Commits nach den konkret getesteten Ausfällen erhalten bleiben | Nicht getestetes Verhalten bei Stromausfall oder Replikation |
| Version und Konfiguration | Prüfsumme des Builds oder Images, Treiberversion, Schema, Einstellungen, Topologie und Testrevision | Gleichwertiges Verhalten eines anderen Builds oder einer anderen Installation |
| Offene Prüfungen | Ungeprüfte Anforderungen, gemeldete Korrekturen, Verantwortliche für den erneuten Test und Folgen für die Einführung | Dass noch ungeprüfte Anforderungen erfüllt sind |

Bewahren Sie für jedes Ergebnis Ausgangszustand, Operationen, erwartetes und beobachtetes Ergebnis auf. Halten Sie genügend Protokolle oder einen Transaktionsverlauf fest, damit andere Entwickler Ihre Interpretation hinterfragen können. Ein grünes Dashboard hilft wenig, wenn niemand weiß, was die Tests tatsächlich geprüft haben.

## Prüfen Sie PostgreSQL-Kompatibilität mit Ihrer Anwendung

Verstehen Sie Kompatibilität als eine Reihe einzelner Anforderungen. Die [Protokolldokumentation von PostgreSQL](https://www.postgresql.org/docs/18/protocol.html) beschreibt den Nachrichtenaustausch zwischen Clients und Servern. Eine Verbindung über dieses Protokoll deckt nur einen Teil dessen ab, was Ihre Anwendung benötigt.

Testen Sie die Treiberfunktionen, die Sie nutzen werden, und anschließend die SQL-Funktionen dahinter. Beziehen Sie Integritätsbedingungen, Nullwerte, numerische Grenzwerte und Fehlerbehandlung ein, soweit diese Ihre Regeln betreffen. Führen Sie die tatsächlichen Abfragen der Anwendung aus, auch seltenere Vorgänge wie einen administrativen Export.

Wenn Sie Ergebnisse mit PostgreSQL vergleichen, legen Sie vorher zulässige Unterschiede fest. Unsortierte Zeilen müssen nicht in derselben Reihenfolge eintreffen. Numerische Genauigkeit, der Prüfzeitpunkt von Integritätsbedingungen und der Vorrang einzelner Fehlermeldungen brauchen eigene Anforderungen. Bewerten Sie eine Abweichung anhand des dokumentierten Verhaltens und Ihrer Anwendung, statt jede Abweichung als Fehler einzustufen.

## Prüfen Sie eine Kapazitätsgrenze am Beispiel

Nehmen Sie einen **hypothetischen Workshop mit 30 Plätzen und 29 bestätigten Reservierungen**. Jede Reservierungstransaktion zählt die bestätigten Buchungen, fügt nur bei freier Kapazität eine weitere ein und schließt dann mit einem Commit ab. Dieses Beispiel ist konstruiert. Wir haben es gegen keine Datenbank ausgeführt.

Planen Sie eine Prüfung mit zwei getrennten Clients:

1. Starten Sie beide Transaktionen gleichzeitig. Können beide 29 Reservierungen zählen, bevor eine davon einen Datensatz einfügt, halten Sie diesen Ablauf fest. Protokollieren Sie blockierte Zugriffe, falls die Engine den Zugriff bereits vorher serialisiert.
2. Lassen Sie beide Transaktionen den bedingten Einfügevorgang und den Commit versuchen. Erfassen Sie Anweisungsergebnisse, Commit-Bestätigungen und Fehler getrennt.
3. Lesen Sie den maßgeblichen Endzustand über eine neue Verbindung aus und prüfen Sie die Kapazitätsregel.
4. Scheitert eine Transaktion an einem Serialisierungsfehler, wiederholen Sie die gesamte Transaktion aus Lesen, Prüfen und Schreiben. Halten Sie die daraus folgende Entscheidung fest.

Bei zugesicherter Serialisierbarkeit muss die Wirkung erfolgreich festgeschriebener Transaktionen einer möglichen sequenziellen Ausführung entsprechen. Mit dieser Transaktionslogik würden zwei neue Bestätigungen, die die Gesamtzahl auf 31 erhöhen, diese Zusicherung verletzen. Stattdessen könnte eine Transaktion scheitern und bei der Wiederholung feststellen, dass der Workshop ausgebucht ist.

Die [Dokumentation zur Transaktionsisolation in PostgreSQL](https://www.postgresql.org/docs/18/transaction-iso.html) erläutert sowohl Serialisierbarkeit als auch die notwendige Wiederholung ganzer Transaktionen. Sie beschreibt außerdem, dass unter Repeatable Read Serialisierungsanomalien möglich sind. Entscheiden Sie sich für schwächere Garantien, die das problematische Zusammenspiel zulassen, weist eine Überbuchung auf eine Unvereinbarkeit zwischen Ihrer Anwendung und diesen Garantien hin. Sie belegt für sich genommen keinen Datenbankfehler.

Eine Zeitüberschreitung beim Client braucht einen eigenen Ergebnisstatus in Ihren Aufzeichnungen. Bricht die Verbindung während des Commits ab, weiß der Client möglicherweise nicht, ob seine Reservierung gespeichert wurde. Klären Sie diese Ungewissheit anhand einer stabilen Vorgangskennung, bevor Sie den Geschäftsvorgang wiederholen.

Speichern Sie bei diesem Entwurf die Kennung atomar zusammen mit der Reservierung, erzwingen Sie ihre Eindeutigkeit und verwenden Sie sie bei Wiederholungen erneut. Ein vorübergehend fehlender Datensatz beweist allein nicht, dass die ursprüngliche Transaktion nach der Zeitüberschreitung zurückgerollt wurde. Eine Isolationsstufe der Datenbank verhindert für sich genommen weder doppelte Bestätigungs-E-Mails noch doppelte Zahlungsbelastungen durch Ihre Anwendung.

## Beziehen Sie Dauerhaftigkeitszusagen auf konkrete Ausfälle

Klären Sie, was die Datenbank mit den vorgesehenen Einstellungen zusichert, wenn sie einen Commit bestätigt. Wählen Sie anschließend Tests, die diese Zusage prüfen.

Die [Dokumentation zum asynchronen Commit in PostgreSQL](https://www.postgresql.org/docs/18/wal-async-commit.html) liefert ein konkretes Beispiel: In dieser Konfiguration können bereits bestätigte Transaktionen bei einem Absturz verloren gehen. Das ist eine dokumentierte Abwägung, kein Verstoß gegen die konfigurierte Garantie.

Erfassen Sie in einer isolierten Testumgebung die Kennungen bestätigter Vorgänge, lösen Sie den gewählten Ausfall aus und vergleichen Sie die wiederhergestellten Datensätze. Kennzeichnen Sie Vorgänge mit unklarem Ausgang getrennt von bestätigten Commits. Das Beenden eines Serverprozesses bildet keinen Stromausfall der Speicherhardware nach. Der Neustart eines Knotens prüft auch keinen Wechsel auf eine Replik. Die [Zuverlässigkeitsdokumentation von PostgreSQL](https://www.postgresql.org/docs/18/wal-reliability.html) erläutert, warum die beteiligten Speicherkomponenten für die dauerhafte Speicherung entscheidend sind.

Stimmen Sie die Nachweise auf die vorgesehene Installation ab. Benötigen Sie bei einem Ausfall einen Wechsel zwischen Regionen, beantwortet ein erfolgreicher lokaler Neustart diese Anforderung noch nicht.

## Unterscheiden Sie zwischen korrigiert und erneut geprüft

Die Korrekturmeldung eines Anbieters ist eine nützliche Information. Halten Sie ihre Herkunft und die genaue Version neben dem Ergebnis fest, bis das erforderliche Verhalten erneut geprüft wurde.

Dokumentieren Sie, welches Reproduktionsszenario erneut ausgeführt wurde, ob auch die übrige Testlast lief und ob sich Build oder Konfiguration geändert haben. Unterscheiden Sie zwischen **Test bestanden**, **Test fehlgeschlagen**, **Korrektur laut Anbieter, erneuter Test ausstehend** und **ungeprüft**. Ein bestandenes Reproduktionsszenario belegt nicht, dass alle verwandten Fälle abgedeckt sind. Auch eine umfassendere bestandene Testsuite beweist keine allgemeine Korrektheit.

Lassen Sie fehlende Nachweise die Entscheidung beeinflussen. Angenommen, eine Datenbank besteht Ihre SQL-Prüfungen. Für die vorgesehene Installation fehlt aber der Nachweis, dass bestätigte Schreibvorgänge beim Umschalten auf ein Ersatzsystem erhalten bleiben. Ist dieser Erhalt zwingend, belassen Sie die führenden Buchungsdaten im bisherigen Speicher. Sie könnten die neue Datenbank trotzdem für einen Suchindex bewerten, der sich neu aufbauen lässt und eigene Anforderungen hat. Lassen Sie die offene Anforderung nicht in einer Gesamtpunktzahl untergehen und geben Sie dann beide Einsatzzwecke frei.

## Dokumentieren Sie eine nachvollziehbare Entscheidung

Halten Sie zum Abschluss den geplanten Einsatz, die erforderlichen Garantien, die genau geprüfte Installation, Links zu Nachweisen und offene Anforderungen fest. Benennen Sie, wer jedes verbleibende Risiko akzeptiert und welche neuen Nachweise die Entscheidung ändern würden. Erfassen Sie Leistungswerte für dieselbe Konfiguration, damit Geschwindigkeitsvergleiche aussagekräftig bleiben.

Wenn Sie anschließend einen Umzug freigeben, behandelt unser [Artikel zur Deno-Deploy-Migration](/blog/deno-deploy-shutdown-migration-tests) die gesonderte Arbeit: das Zielsystem prüfen und die Umstellung vorbereiten. Die Entscheidung hier fällt früher: Gibt es genügend Nachweise dafür, dass diese Datenbank die vorgesehene Rolle in Ihrer Anwendung erfüllen kann? Beginnen Sie mit der Regel, deren Verletzung Sie sich nicht leisten können. Halten Sie die Einführungsentscheidung offen, bis die erforderlichen Nachweise vorliegen.