Jepsen Tests ParticleDB 1.1.4, but Only on a Single Node

Jepsen has published an analysis of ParticleDB 1.1.4, a multi-model database built for AI workloads, and the report covers only single-node behaviour. The report is dated 31 October 2026. The builds Orkes provided did not support replication, so the testing covered one database process running on one machine.

Orkes engaged Jepsen to test refactored versions of ParticleDB. Version 1.1.4 is the first release in that effort, and the published analysis is the first output of that work. Its scope follows the build under test, not the full product.

The test harness could simulate process crashes by killing the ParticleDB process. It also used LazyFS, a filesystem layer that simulates the loss of writes that had not been fsynced, meaning writes the operating system had not yet forced onto stable storage. Together, the two techniques target the durability path. They check whether data a client was told had been committed survives an abrupt stop, and what the database can and cannot recover when the filesystem drops buffered data. A write acknowledged before it reached stable storage is exactly the kind of state a crash can erase, so the fsync boundary is where a single-node store's durability claims either hold or do not.

Replication raises most of the harder distributed-systems questions. These include how writes propagate between nodes, what a client observes during a network partition, and how leadership changes affect acknowledged data. Because the Orkes builds lacked replication, none of those questions fall within the report. Readers should treat it as a statement about one ParticleDB process on one disk. Any deployment that depends on replicated durability will need separate evidence.

Orkes publishes official ParticleDB content on orkes.io.

The broader context here is the growing use of databases to store agent memory, retrieval state and workflow records, where a lost write can silently change what a downstream system does. Testing that targets crash recovery and unsynced writes addresses a failure class that functional benchmarks often miss. In my view, the practical value of this engagement lies in the harness itself. A fault-injection setup that kills the process and discards unsynced data can be reused, and the open question for anyone evaluating ParticleDB is how the same discipline will be applied once replicated builds are available for testing.