v1.5.0 — Read-Model beim Append, Nachprojektion, Schluesselgeber Anlass war ein Fehlerbild in der DNS-Editor-Beta: Speichern ueber einen fremden Regionsknoten ging verloren — mal mit Fehler, mal stillschweigend. Vier Aggregate standen im Event-Log, aber nie im Read-Model. Append schreibt die Read-Model-Zeile jetzt in DERSELBEN Transaktion. Der Zustand liegt nach Apply ohnehin im Speicher, es kostet einen Upsert — und WaitFor auf die eigene Position kehrt sofort zurueck, statt bis zu fuenf Sekunden auf einen Projektions-Worker zu warten, der die Lease womoeglich auf einem anderen Knoten haelt. Der Upsert ist nur vorwaerts (aggregate_seq), damit ein Worker, der zu seiner Lesezeit faltet, keinen neueren Stand ueberschreibt. Dazu holt der Worker beim ersten Durchlauf je Model nach, was im Hot-Log steht und im Read-Model fehlt oder zurueckliegt. Zweiter Befund derselben Runde: YugabyteDB bis 2024.2 kennt keine Advisory-Sperren und bricht mit pg_advisory_xact_lock die laufende Transaktion ab. Seit v1.4.1 waere dort JEDER Append gescheitert. Der Dialekt prueft das einmal beim Verbinden und bleibt ohne Sperre beim Wettlauf mit Erkennung — jetzt auch fuer SQLSTATE 40001, mit dem YB unter Snapshot-Isolation denselben Wettlauf meldet. Neu in der API: DB.Keys() gibt den bei Open gesetzten Schluesselgeber heraus. Artefakte ausserhalb der Datenbank brauchen denselben Schluessel — eine Sicherung, die die Felder beim Schreiben entschluesselt, muss sie wieder verschluesseln koennen, und zwar ohne einen zweiten Schluesselweg. Geprueft auf SQLite, PostgreSQL und YugabyteDB 2025.2 sowie seriell gegen YugabyteDB 2024.2.9.1 mit drei Regions-Placements.