ParticleDB 是由 Orkes 开发的多模型数据库，旨在支持其工作流编排平台 Conductor。该系统采用 Rust 构建，旨在将包括事务型 SQL、键值存储、向量搜索和实时分析在内的各种工作负载统一到单个引擎中。尽管开发人员声称该数据库经过“形式化证明”并提供“全 ACID”合规性，但对 1.1.4 至 1.1.18.11.rc-22 版本的 Jepsen 分析揭示了这些声明与系统实际行为之间的重大差异。
分析共识别出 96 个独立问题，其中许多问题发生在健康的单节点实例中，且没有任何模拟故障。这些问题涵盖了从自发崩溃和死锁等基础稳定性问题到更复杂的逻辑异常。例如，报告记录了行变为“部分不可见”且无法删除的情况、查询返回不可能条件（例如 `WHERE 4 = 5`）结果的情况，以及删除的表以扭曲形式重新出现的场景。此外，该数据库还表现出类型安全故障，例如字符串意外变为整数以及混乱的列映射。
Jepsen 分析识别出 96 个独立问题，其中许多问题发生在健康的单节点实例中，且没有任何模拟故障。
主要的工程发现之一涉及数据库的事务隔离模式。尽管 ParticleDB 推销“全 ACID”特性，但分析发现默认的 `occ`（乐观并发控制）模式在正常运行期间仍会丢失已提交的写入。此外，即使设置为通常最强的隔离级别 `serializable`，系统仍允许内部异常和“丢失更新”错误。虽然 Orkes 随后发布了更新版本（1.1.19-rc.13）并声称解决了这些问题，但 Jepsen 报告强调了数据库宣传的安全保证与其在严格测试中表现出的性能之间的显著差距。
除了一致性之外，分析还注意到特定配置下的严重性能瓶颈。在早期版本中，发现 `table-2pl` 事务模式基本不可用，大多数事务在失败前会阻塞 10、20 甚至 30 秒。虽然在后续版本中做出了一些改进，但报告强调，该数据库处理并发和预写日志（WAL）同步的内部机制在不同文档来源中并不一致，导致用户在尝试实现高吞吐量、安全操作时出现不可预测的行为。