ParticleDBは、Orkes社が自社のワークフローオーケストレーションプラットフォームであるConductorをサポートするために開発したマルチモデルデータベースです。Rustで構築されたこのシステムは、トランザクションSQL、キーバリューストレージ、ベクトル検索、ライブ分析を含むさまざまなワークロードを単一のエンジンに統合することを目的としています。開発者はこのデータベースが「形式的に証明」されており、「完全なACID」準拠を提供していると主張していましたが、Jepsenによるバージョン1.1.4から1.1.18.11.rc-22までの分析では、これらの主張とシステムの実際の動作との間に重大な乖離があることが明らかになりました。
分析では96件の異なる問題が特定されましたが、その多くはシミュレートされた障害がない健全なシングルノードインスタンスで発生していました。これらの問題は、自発的なクラッシュやデッドロックといった基本的な安定性の問題から、より複雑な論理的異常まで多岐にわたります。例えば、レポートでは、行が「部分的に不可視」になり削除できなくなるケース、クエリが不可能な条件（例：`WHERE 4 = 5`）に対して結果を返すケース、削除されたテーブルが歪んだ形で再出現するシナリオなどが記録されました。さらに、文字列が予期せず整数に変わったり、列のマッピングが混乱したりするなど、型安全性の失敗も示されました。
Jepsenの分析では、シミュレートされた障害がない健全なシングルノードインスタンスで発生した96件の異なる問題が特定されました。
主な技術的発見の一つは、データベースのトランザクション分離モードに関するものでした。ParticleDBは「完全なACID」特性を宣伝していましたが、分析の結果、デフォルトの`occ`（楽観的同時実行制御）モードでは、通常の動作中にコミットされた書き込みが失われ続けていることが判明しました。さらに、通常最も強力な分離設定である`serializable`に設定されている場合でも、システムは内部的な異常や「Lost Update（更新の紛失）」エラーを許容していました。Orkes社はその後、これらの問題を解決したと主張する新しいバージョン（1.1.19-rc.13）をリリースしていますが、Jepsenのレポートは、データベースの宣伝されている安全性保証と、厳格なテストにおける実際のパフォーマンスとの間に大きな隔たりがあることを強調しています。
一貫性だけでなく、分析では特定の構成における深刻なパフォーマンスのボトルネックも指摘されました。初期のバージョンでは、`table-2pl`トランザクションモードは事実上使用不可能であり、ほとんどのトランザクションが失敗する前に10秒、20秒、あるいは30秒間ブロックすることが判明しました。後のバージョンでいくつかの改善が行われましたが、レポートは、同時実行処理や書き込み先行ログ（WAL）の同期を処理するためのデータベース内部のメカニズムが、異なるドキュメントソース間で一貫していないことを強調しています。これにより、高スループットで安全な操作を実現しようとするユーザーにとって、予測不可能な動作を招く原因となっています。