Jepsen finds 96 ParticleDB faults, including lost committed writes on a single node

On October 31, 2026, Kyle Kingsbury published a Jepsen analysis commissioned by Orkes of its Postgres-compatible ParticleDB engine. Jepsen tested versions 1.1.4 through 1.1.18.11.rc-22 and catalogued 96 issues, including loss of committed writes, transaction isolation violations, crashes, deadlocks, invalid SQL results and data corruption. Almost all findings arose on healthy single-node instances without injected faults. Many issues were fixed or improved during the engagement; however, Jepsen still reproduced committed-write loss in the default optimistic concurrency mode and anomalies under stricter modes in the latest tested builds. Orkes says newer, untested builds address remaining problems. Jepsen's public test harness documents the workloads and some known limitations.

A database may appear to accept a transaction and then silently lose it. That is a more consequential failure than a crash, because applications may continue acting on incorrect balances, inventory, jobs or customer records without knowing the source of the error. Builders considering an AI-oriented, Postgres-compatible database should demand independent verification of the exact release, transaction mode, durability settings and migration path rather than relying on generic ACID or compatibility marketing. The report also illustrates how extensive test-driven repair can improve a young engine while still leaving critical correctness gaps.

Jepsen examined ParticleDB 1.1.4 through 1.1.18.11.rc-22, using single-node deployments, multiple transaction modes, Postgres and ParticleDB client interfaces, and a range of WAL settings. The test suite compared selected SQL behaviour with PostgreSQL and exercised append, read/write and internal consistency workloads. These findings establish behaviour for tested versions and configurations, not for every deployment or later unretested release. The public harness notes that it has not tested replication and that some SQL comparison workloads can produce false positives, so findings should be read at their individual evidence level.

The investigation found successful writes that later disappeared from reads, along with aborted or intermediate reads, lost updates and serialization anomalies. Jepsen reports that the default optimistic-concurrency mode still lost acknowledged writes in the latest versions it tested; stronger serializable settings reduced but did not eliminate anomalies. Acknowledgement without durable persistence creates a recovery and correctness risk that ordinary uptime monitoring cannot detect.

The report documents examples in earlier builds where NOT NULL and UNIQUE constraints were not enforced, primary-key updates created duplicates, WHERE predicates returned incorrect rows, joins omitted or confused values, and rows could become difficult to update or delete. Many examples were addressed during the engagement. The point is not that every one persists today, but that compatibility and correctness claims need testing against the precise deployed build.

Orkes funded the testing and collaborated on successive fixes. The report attributes to Orkes the position that newer 1.1.19 release candidates resolve remaining issues and that earlier production customers may have used a different 1.0 engine. Jepsen did not independently verify all claimed later repairs, and its brief check of a 1.0 build was not a comprehensive production or replication audit. Neither a blanket claim that all ParticleDB versions are broken nor a claim that all defects are now fixed follows from the published evidence.

Identify the exact ParticleDB binary and mode in use. Reproduce transaction and SQL workloads against that version, confirm durability under restart and fault conditions, compare representative queries against PostgreSQL, and test application-specific invariants. Keep recoverable backups and a migration route to an independently validated alternative until critical invariants are demonstrated. Do not assume that a successful COMMIT or a vendor-reported fix is sufficient evidence of correctness.