Jepsen分析: ParticleDB 1.1.4の安全性と正確性

エグゼクティブサマリー

AIワークロード向けに販売されているマルチモデルデータベース「ParticleDB 1.1.4」は、Jepsenのテストにおいて「完全なACID」準拠という主張を満たすことができませんでした。分析の結果、基本的なSQL構文の失敗から、深刻なデータ破損、書き込みの消失、さらには単一ノードかつ障害のない環境でさえ発生するトランザクションの異常まで、96件もの個別の問題が明らかになりました。その後のリリース候補版でこれらのバグの多くは修正されましたが、今回の調査結果は、このデータベースの開発および品質保証プロセスに根本的な欠陥があることを示唆しています。

ParticleDBの現状

ParticleDBは、Orkesが自社のオーケストレーションプラットフォーム「Conductor」をサポートするために設計したもので、SQL、キーバリュー、ベクトル検索のワークロードを統合することを目指していました。 「形式的に証明済み」であり「Postgresよりも桁違いに高速」であるというマーケティング上の主張にもかかわらず、テストされたバージョン（1.1.4から1.1.18.11.rc-22）は極めて不安定でした。

主な調査結果は以下の通りです：

• データ破損: データベースは頻繁にコミットされた書き込みを消失させ、単純なクエリに対して誤った結果を返し、削除や更新ができない「ゾンビ」行を許容しました。
• トランザクションの失敗: 強力な分離設定下であっても、システムはスナップショット分離や直列化可能性の違反を示し、更新消失（Lost Updates）や古いデータの読み取り（Stale Reads）が発生しました。
• SQLの非互換性: WHERE句、JOIN、集計関数などの基本的な操作で、頻繁に誤ったデータが返されたり、内部エラーが発生したりしました。
• システム的な不安定さ: データベースは、障害注入を行っていない状況でも、自発的なデッドロックやクラッシュに見舞われました。

品質保証に関する洞察

Jepsenのレポートは、データベースのマーケティングと実際の実装との間の懸念すべき乖離を浮き彫りにしています。「形式的に証明済み」という主張は、利用可能なTLA+仕様によって裏付けられておらず、ドキュメントには誤ったデフォルトのユーザー名や存在しないSDK依存関係など、捏造された内容が頻繁に含まれていました。

Hacker Newsのあるコメント投稿者が指摘したように、WHERE 4 = 5 が行を返すといった「低レベルな」バグの多さは、基本的な自動テストの欠如を示唆しています。コメント投稿者は、このプロジェクトが「バイブコード（vibecoded）」されているか、十分な人間の監視や検証なしにLLMに大きく依存しているのではないかと推測しました。あるユーザーは次のように述べています：

「彼らの主張のあまりの傲慢さと、壊れたゴミのようなソフトウェアという具体的な現実……文字通り息をのむほどだ。」

推奨事項

Jepsenは、ユーザーに対してParticleDBのデプロイを停止し、より信頼性の高い代替手段へ移行することを推奨します。開発者にとって、このレポートは、厳格な品質保証や形式検証を回避する、LLM支援による急速な開発サイクルに伴うリスクを痛烈に思い出させるものとなっています。

Orkesはその後、ドキュメントを更新してテストされたモードを「実験的」とラベル付けし、バージョン 1.1.19-rc.13 で報告された問題が解決されたと主張しています。しかし、Jepsenは、透明性のある再現可能なテストと正確なドキュメントを通じて正確性を証明する責任はベンダーにあるという立場を維持しています。