分布式系统测试机构 Jepsen 于 2026 年 10 月 31 日发布报告，对工作流编排厂商 Orkes 旗下的 AI 多模数据库 ParticleDB（覆盖 1.1.4 至 1.1.18.11.rc-22 版本）进行了严苛体检，共揪出 96 个漏洞。这款用 Rust 从头编写的数据库，试图用一个底层引擎同时包揽事务型 SQL、Redis 键值存储、向量搜索和实时分析，并曾在宣传中打出完整 ACID、159K TPS 以及比 PostgreSQL 快 1,087 倍的旗号。但 Jepsen 的测试撕开了全能 AI 数据库的营销包装，证明用现代语言重写执行器并不能跳过数据库内核最苦的并发控制与事务隔离打磨。
更反常的是这批漏洞的触发条件。以往登上 Jepsen 榜单的数据库，大多倒在复杂的跨节点网络分区或磁盘故障注入下；而 ParticleDB 暴露出的 96 个问题里，有 93 个无需注入任何故障，仅在健康的单节点、单客户端正常读写中就会复现。从进程崩溃、死锁、丢失已提交数据，到无法删除的半隐形行、被删除的表以扭曲形态复活、字符串自动变成整数，甚至连 WHERE 4 = 5 这种基础逻辑判断都会失灵。直到测试收尾的 1.1.18.11.rc-22 版本，默认的 occ 事务模式依然会在正常运行时弄丢已确认写入，最严格的 serializable 模式也照样出现丢失更新（Lost Update）。
消失的 TLA+ 证明与千倍性能神话
一家数据库创业公司敢在官网首页宣称完整 ACID 与秒杀级性能，通常需要极强的工程背书，但 ParticleDB 的安全承诺在细究之下几乎全线失守。官方主页曾高调宣传系统经过 TLA+ 形式化验证，然而在 Jepsen 介入测试的整个合作周期里，Orkes 根本拿不出任何 TLA+ 规范文档。同样自相矛盾的还有隔离级别：官网大字写着 Full ACID，紧挨着的下一行小字却标注着并不具备完全隔离性的快照隔离（Snapshot Isolation）；当客户端通过标准 SQL 发送 SET TRANSACTION ISOLATION LEVEL 指令时，系统要么直接拒绝，要么表面接收却在底层静默忽略，转而由启动时的命令行参数强行接管。
更让外界意外的是其性能神话的缩水。ParticleDB 曾宣传比 PostgreSQL 快 1,087 倍，且具备同等安全性。Jepsen 在 Debian 13 节点上用 Clojure 编写了差分测试工具，一边向 ParticleDB 和 PostgreSQL 同时喂入只包含基础数据类型与简单布尔逻辑的随机 SQL，一边观测吞吐表现。结果不仅基础 SQL 语义对不上，Jepsen 也未能复现出接近官方宣传的性能，反而在持续一小时的常规运行中，观测到其吞吐量持续衰减、中位延迟一路飙升。测试报告公开前后，ParticleDB 修改了基准测试文档，明确表态在没有可复现结果包的情况下，不再沿用过去的对比性性能标题，同时将文档中的默认隔离级别低调改写为较弱的 READ COMMITTED。
兼容了 PostgreSQL 的通信协议，不等于继承了它三十年千锤百炼的事务确定性。
试图吞下 Postgres 与 Redis 的底层撕裂
Orkes 造这颗轮子的初衷并不难理解。其核心产品是工作流编排平台 Conductor，早期底层依赖 Redis 加 PostgreSQL 的组合，为了帮 AI Agent 等高频状态交互场景省去跨库同步的延迟与运维麻烦，团队决定用 Rust 自研一个全能底座。这也是当下 AI 基础设施领域最讨喜的叙事：用一个多模引擎把关系表、缓存、向量和 OLAP 全装进去。
但把两套截然不同的存储哲学硬塞进同一个进程，很快就会在持久化和事务边界上产生工程撕裂。即便在 Orkes 紧急修订后的最新架构文档里，这种分裂依然存在：当开发者通过 SQL 接口提交事务时，数据默认走同步持久化；但通过其兼容的 Redis 端点写入键值数据时，系统默认采用异步 KV 持久性。这意味着一旦遭遇操作系统崩溃或机房断电，业务端明明已经收到写入成功确认的缓存或状态数据，依然会直接丢失。
一份未验证的修复声明，与尚待检验的分布式深水区
值得肯定的是，这项揭短的测试并非外部突袭，而是由 Orkes 自己出资聘请 Jepsen 完成的。Orkes 解释称，现网生产环境的 Conductor 客户目前运行的仍是功能受限的 1.0.0 版本，本次送测的 1.1.x 属于大重构后的软启动版本。2026 年 10 月 26 日，Orkes 推出了 1.1.19-rc.13 候选版，并在 10 月 30 日的官方博客中宣称报告提及的所有 96 个问题已全部解决。
但对于正在选型的技术团队和架构师而言，警报远未解除。所谓全部修复的 1.1.19-rc.13 连正式版（GA）都不是，且未经 Jepsen 重新测试与独立验证。更关键的盲区在于，ParticleDB 企业云版本主打基于 Raft 协议的多节点复制集群，但 Orkes 此次提供给 Jepsen 的安装包根本不包含复制功能。
- 风险.正在使用 Orkes Conductor 并考虑升级到底层 1.1.x 引擎的企业，以及被全能 AI 数据库概念吸引的架构师，切忌在生产环境盲目替换掉成熟的 PostgreSQL 与 Redis 组合。单节点无故障尚且测出 93 个漏洞，一旦进入尚未经过独立检验的 Raft 多节点分布式环境，跨节点数据一致性的风险完全未知。接下来最该紧盯的三个硬指标，是 Orkes 能否公开可复现的性能测试包、能否拿出真正的 TLA+ 规范，以及敢不敢出资让 Jepsen 对 1.1.19 正式版的多节点集群做二次验证。