ParticleDB discarded acknowledged writes on a healthy single server in Jepsen's audit. This October 31, 2026 review examines the available audit and current release documentation. The audit's publication date is unverified in the supplied evidence; this review does not establish when Jepsen published its findings.
Jepsen tested versions 1.1.4 through 1.1.18.11.rc-22 and reported 96 issues. For developers evaluating the database for application records, the immediate question is which findings apply to their build and configuration.
Orkes, which built ParticleDB and engaged Jepsen to test it, claims all issues in the report were addressed as of 1.1.19-rc.13. Jepsen has not evaluated versions after 1.1.18.11.rc-22. The findings establish failures in tested builds; the later fixes remain vendor claims. The release page lists ParticleDB 1.1.19-rc.16, released October 30, 2026, and labels the server a release candidate. That date belongs to the software release, not the audit.
A successful commit could disappear
Jepsen found acknowledged-write loss in healthy nodes running versions 1.1.18.11.rc-18 through 1.1.18.11.rc-22 with occ-v3, zero-copy-occ, table-2pl or serializable-ssi. These failures did not require an injected crash or disk fault.
In the report's lost-writes example, a transaction committed successfully, and several other transactions read its write. Later values replaced the earlier values, which never reappeared. Out of approximately 20,000 keys, 31 lost writes in that run, despite using WAL mode sync.
The audit covered single-node behavior. The supplied builds did not support replication, so the findings do not evaluate ParticleDB's replicated cluster. Near the end of the engagement, Jepsen also briefly evaluated an internal 1.0.0 build. It exhibited some string and arithmetic issues but did not seem susceptible to most of the serious safety errors found in 1.1.4. That limited observation does not establish the safety of every 1.0.0 deployment.
Upgrading requires checking storage and configuration
Orkes' release history documents a storage-format boundary at 1.1.19-rc.14. That build refuses data directories written by earlier builds and leaves their files untouched. The documented migration is to export tables with the earlier build and load them into a new data directory. Release rc.15 retains that restriction for rc.13 and older directories and upgrades rc.14 directories in place, one way. Release rc.16 opens rc.15 directories in place.
Release rc.16 also removes --txn-mode and --wal-sync-mode. The current configuration reference separates transaction isolation, conflict detection and durability. For SQL transactions, the documented defaults are READ COMMITTED isolation, optimistic concurrency control and groupsync durability. Orkes documents strict-optimistic with SERIALIZABLE isolation as providing strict serializability. Jepsen has not verified those current configuration guarantees.
KV commands on the Redis-compatible endpoint have a separate durability setting, --kv-durability, which defaults to async. The documentation says an OS crash or power loss can lose recent acknowledged KV writes with that setting. KV writes over the native PDB wire follow --durability instead. Operators need to check the setting for the interface their application uses.
The current documentation describes the older transaction modes as experimental and unsupported. It also acknowledges that independent testing found safety errors in those builds and states that removing a mode does not change the findings about builds that accepted it. Its instruction to affected operators is explicit: upgrade, choose a current mode and check existing data against a trusted source.
For an operator, those are separate tasks. Identify the exact deployed version, interface and settings, plan any required export and reload, and check records written by the affected build. A newer binary alone does not establish that those records are intact. A follow-up evaluation would need to record the exact version and configuration and distinguish single-node results from replication testing.