Jepsen 分析：ParticleDB 1.1.4 的安全性和正确性

执行摘要

ParticleDB 1.1.4 是一款面向 AI 工作负载的多模型数据库，但在 Jepsen 的测试中未能达到其宣称的“完全 ACID”合规性。分析发现了 96 个不同的问题，从基本的 SQL 语法错误到严重的数据损坏、写入丢失以及即使在单节点、无故障环境中也会发生的事务异常。尽管后续的候选发布版本修复了其中许多错误，但这些发现表明该数据库的开发和质量保证流程存在根本性缺陷。

ParticleDB 的现状

ParticleDB 由 Orkes 设计，旨在支持其 Conductor 编排平台，目标是统一 SQL、键值和向量搜索工作负载。尽管其营销宣称“经过形式化验证”且“速度比 Postgres 快几个数量级”，但所测试的版本（1.1.4 到 1.1.18.11.rc-22）表现出极大的不稳定性。

主要发现包括：

• 数据损坏： 数据库频繁丢失已提交的写入，对简单查询返回错误结果，并允许存在无法删除或更新的“僵尸”行。
• 事务失败： 即使在强隔离设置下，系统也表现出违反快照隔离（Snapshot Isolation）和可串行化（Serializability）的情况，包括丢失更新（Lost Updates）和陈旧读取（Stale Reads）。
• SQL 不兼容： 基本操作（如 WHERE 子句、JOIN 和聚合函数）经常返回错误数据或抛出内部错误。
• 系统性不稳定： 即使在没有故障注入的情况下，数据库也会出现自发的死锁和崩溃。

关于质量保证的见解

Jepsen 的报告强调了该数据库的营销宣传与其具体实现之间令人担忧的差距。所谓的“经过形式化验证”的声明没有任何可用的 TLA+ 规范支持，且文档中经常包含虚假信息，例如错误的默认用户名和不存在的 SDK 依赖项。

正如 Hacker News 上的一位评论者所指出的，大量“低级”错误（例如 WHERE 4 = 5 竟然返回了行）表明该项目缺乏基本的自动化测试。评论者推测该项目可能是“凭感觉编码”（vibecoded）或在没有足够人工监督或验证的情况下过度依赖 LLM。正如一位用户所言：

“他们宣称的傲慢与他们那破碎的垃圾软件的具体现实相结合……简直令人叹为观止。” — @handle

建议

Jepsen 建议用户停止部署 ParticleDB 并迁移到更可靠的替代方案。对于开发者而言，该报告严厉提醒了那些绕过严格质量保证和形式化验证、快速进行 LLM 辅助开发周期所带来的风险。

Orkes 此后更新了其文档，将测试的模式标记为“实验性”，并声称 1.1.19-rc.13 版本解决了报告的问题。然而，Jepsen 坚持认为，供应商有责任通过透明、可重复的测试和准确的文档来证明其正确性。