ParticleDB is a multi-model database developed by Orkes to support their workflow orchestration platform, Conductor. Built in Rust, the system aims to unify various workloads—including transactional SQL, key-value storage, vector search, and live analytics—into a single engine. While the developers claimed the database was "formally proven" and offered "Full ACID" compliance, a Jepsen analysis of versions 1.1.4 through 1.1.18.11.rc-22 revealed significant discrepancies between these claims and the system's actual behavior.
The analysis identified 96 distinct issues, many of which occurred in healthy, single-node instances without any simulated faults. These problems ranged from basic stability issues like spontaneous crashes and deadlocks to more complex logical anomalies. For example, the report documented instances where rows became "partially-invisible" and could not be deleted, cases where queries returned results for impossible conditions (e.g., `WHERE 4 = 5`), and scenarios where dropped tables would re-emerge in distorted forms. Furthermore, the database exhibited type-safety failures, such as strings unexpectedly turning into integers and confused column mappings.
The Jepsen analysis identified 96 distinct issues, many of which occurred in healthy, single-node instances without any simulated faults.
One of the primary technical findings involved the database's transaction isolation modes. Although ParticleDB marketed "Full ACID" properties, the analysis found that the default `occ` (Optimistic Concurrency Control) mode continued to lose committed writes during normal operation. Additionally, the system allowed internal anomalies and "Lost Update" errors even when set to `serializable`, which is typically the strongest isolation setting. While Orkes has since released a newer version (1.1.19-rc.13) claiming to resolve these issues, the Jepsen report highlights a significant gap between the database's advertised safety guarantees and its performance in rigorous testing.
Beyond consistency, the analysis also noted severe performance bottlenecks in specific configurations. In earlier versions, the `table-2pl` transaction mode was found to be essentially unusable, with most transactions blocking for 10, 20, or even 30 seconds before failing. While some improvements were made in later versions, the report underscores that the database's internal mechanisms for handling concurrency and write-ahead log (WAL) synchronization were inconsistent across different documentation sources, leading to unpredictable behavior for users attempting to achieve high-throughput, safe operations.