Jepsen zerlegt ParticleDBs ACID-Versprechen
Wenn Jepsen eine Datenbank testet, geht es nicht um Kosmetik. Es geht um die Frage, ob ein System unter Last, bei Ausfällen und in verteilten Setups noch das hält, was das Marketing verspricht. Bei ParticleDB fällt das Urteil hart aus: Die Bezeichnung „Full ACID“ war in den geprüften Versionen zu früh.
Getestet wurden laut Jepsen Versionen von 1.1.4 bis 1.1.18.11.rc-22. Der zentrale Punkt ist dabei nicht ein einzelner Bug. Das Problem liegt tiefer. Wer mit ACID wirbt, verspricht Anwendungsentwicklern verlässliche Transaktionen, Konsistenz und ein sauberes Verhalten auch dann, wenn das System unter Druck gerät. Wenn genau das nicht belastbar ist, wird aus einem Feature-Claim schnell ein Risiko für produktive Systeme.
Das ist für Datenbanknutzer mehr als eine akademische Debatte. ACID ist kein Etikett für die Website, sondern eine harte Zusage. Teams bauen darauf ihre Geschäftslogik. Sie verlassen sich darauf, dass Buchungen nicht verschwinden, dass Zustände nicht auseinanderlaufen und dass konkurrierende Schreibzugriffe sauber aufgelöst werden. Wenn diese Annahmen wackeln, trifft das direkt Anwendungen, Betriebsprozesse und am Ende auch Vertrauen.
Gerade im Datenbankmarkt ist das heikel. Viele jüngere Systeme wollen klassische relationale Garantien mit der Skalierung verteilter Architekturen verbinden. Das Ziel ist attraktiv, die Umsetzung schwierig. Genau an dieser Stelle sind unabhängige Belastungstests wichtig. Sie prüfen nicht, ob ein Feature auf dem Papier existiert, sondern ob es in realen Fehlerszenarien standhält.
Für ParticleDB ist der Vorgang deshalb unangenehm, weil Jepsen in der Szene als Gradmesser gilt. Wer dort bei Konsistenz- und Transaktionsfragen schlecht abschneidet, bekommt kein PR-Problem, sondern ein Glaubwürdigkeitsproblem. Technische Entscheider lesen so etwas sehr genau. Denn bei Datenbanken ist Vertrauen ein Kernprodukt. Geht das verloren, hilft auch eine lange Feature-Liste wenig.
Die größere Lehre geht aber über ParticleDB hinaus. Hersteller verteilter Datenbanken sollten bei Begriffen wie ACID extrem sauber sein. Zwischen „unter bestimmten Bedingungen verfügbar“ und „voll belastbar in verteilten Fehlerfällen“ liegt ein großer Unterschied. Wer diese Lücke sprachlich zukleistert, lädt genau solche Korrekturen ein.
Für Entwickler und Architekten ist die Sache ebenfalls klar: Claims zu Konsistenz, Isolation und Transaktionen sollte man nicht als gegeben hinnehmen. Gerade bei jungen Datenbanksystemen zählt weniger das Datenblatt als das Verhalten unter Störung. Je höher der geschäftliche Schaden bei inkonsistenten Daten wäre, desto härter muss die Prüfung ausfallen.
ParticleDB steht damit an einem Punkt, den viele ambitionierte Datenbankprojekte irgendwann erreichen: Entweder die Architektur und die Implementierung holen die großen Versprechen ein, oder die Versprechen müssen kleiner werden. Beides ist legitim. Problematisch wird es erst, wenn Marketing weiter ist als das System selbst.
