ParticleDB is a multi-model database built by Orkes, the company behind the Conductor workflow orchestration platform. Written in Rust, it promises transactional SQL, key-value storage, vector search, live analytics, and user-defined functions called Particles — all unified in one engine aimed squarely at AI workloads. The homepage claimed "Full ACID. 159K TPS." Jepsen tested that claim. The results are brutal. Across versions 1.1.4 through 1.1.18.11.rc-22, Jepsen catalogued 96 distinct issues. The mundane ones — crashes, deadlocks, data loss — would be damning enough on their own. But the exotic failures are what linger: partially-invisible rows that could not be deleted, WHERE clauses evaluating 4 = 5 as true, dropped tables re-emerging in distorted forms, columns getting confused with each other, and strings spontaneously turning into integers. Most of these issues required just a single server, a single client, and zero injected faults. No network partitions, no crashes — just normal operation. The documentation picture was equally chaotic. ParticleDB's homepage advertised a TLA+ formal proof, but no specification was available during the engagement. The WAL sync documentation contradicted itself across three different sources about what "groupsync" actually guaranteed. The transaction mode documentation was a thicket of conflicting tables: one source described the default "occ" mode as "safe under concurrency," another called it safe for "most OLTP" — an important qualifier that implies some OLTP workloads are unsafe. Orkes acknowledged the documentation was wrong. The transaction isolation story is particularly telling. ParticleDB's homepage claimed "Full ACID" while the text immediately below it specified "snapshot isolation" — which is definitionally not fully isolated. The database ignored or rejected standard SQL SET TRANSACTION ISOLATION LEVEL statements. Instead, isolation was controlled by a startup flag, meaning you couldn't mix isolation levels within a running instance. The operator guide eventually revealed that the default occ mode provided Snapshot Isolation, not Serializable, and only the table-2pl mode offered Strong Serializable — but at the cost of exclusive table locks. By version 1.1.18.11.rc-22, all but ten of the 96 issues appeared resolved. But the remaining ten are not minor: ParticleDB continued to lose committed writes during normal operation under the default occ transaction mode, and allowed internal anomalies and Lost Update even under serializable — the strongest isolation setting available. These are not edge cases; they are fundamental safety violations in the modes users are most likely to run. Orkes funded this research and has since released version 1.1.19-rc.13, claiming it resolves all remaining issues. Notably, Jepsen only tested single-node behavior because Orkes did not provide builds with replication support. The clustered Raft-based replication — available only in enterprise cloud — remains untested. The gap between marketing ("Full ACID," "formally proven," "orders of magnitude faster than Postgres") and the tested reality is wide enough to drive a database through.
