# Jepsen finds 96 ParticleDB faults, including lost committed writes on a single node Jepsen's October 31 investigation of Orkes ParticleDB found data-loss, transaction-isolation and SQL correctness failures across tested 1.1.x builds. Orkes says later fixes exist, but their effectiveness remains independently unverified. ParticleDB's claimed ACID guarantees failed Jepsen tests: acknowledged writes disappeared, queries returned wrong rows, and even healthy single-node tests exposed integrity faults. - Status: Active - Published: 2026-11-01T11:09:18+13:00 - Updated: 2026-11-01T11:09:18+13:00 - Categories: Cloud & Infrastructure, Databases & Storage - Tags: data integrity, databases, PostgreSQL, reliability - Canonical HTML: https://beyondthe.news/dossiers/jepsen-particledb-96-issues-committed-write-loss-acid-2026 ## What changed 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. ## Why it matters 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. ## The tested versions and the scope of the evidence 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. ## Committed-write loss and transaction anomalies 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. ## SQL and integrity failures extended beyond concurrency 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 disputes the implications for newer builds 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. ## Practical checks before adopting or upgrading 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. ## Key details - Jepsen analysis published October 31, 2026, by Kyle Kingsbury; Orkes funded the engagement. - 96 issues reported across tested ParticleDB 1.1.4 through 1.1.18.11.rc-22. - Loss of acknowledged writes, transaction anomalies and SQL integrity faults appeared even without injected failures on a single node. - Many issues were fixed during testing; some severe failures remained in the latest independently tested release candidates. - Orkes claims newer versions fix the remaining problems, but Jepsen did not independently retest all those builds. - Jepsen test harness is public; replication safety was outside its test scope. ## Builder takeaways - Do not rely on ParticleDB ACID claims without validating the precise binary, WAL and transaction configuration. - Test for acknowledged-write durability, not only crash recovery and query latency. - Audit SQL compatibility and constraints using representative application workloads. - Preserve backups and a tested migration path while critical correctness claims remain unverified. ## What to watch - Jepsen independent retest of the newer ParticleDB builds Orkes says fix the findings. - Version-specific public release notes and reproducible transaction-integrity tests. - Evidence about production impact and replicated-cluster behaviour, neither established by this single-node study. ## Uncertainties - The primary Jepsen site was indexed and its public repository inspected, but direct browser opening of the report was intermittently inaccessible. - The test suite documents limitations including occasional false positives in some SQL comparison workloads. - Orkes says later release candidates address outstanding findings; independent validation was not available during this pass. - Results from tested single-node configurations do not establish replication behaviour or a verified production incident. ## Sources - [Jepsen: ParticleDB 1.1.4](https://jepsen.io/analyses/particledb-1.1.4) — Jepsen / Kyle Kingsbury · primary independent technical analysis · 2026-10-31T00:00:00+13:00. Detailed test results, version-specific reproductions, remediation chronology and limitations; indexed text verified, direct page access intermittent. - [ParticleDB Jepsen test harness](https://github.com/jepsen-io/particledb) — Jepsen · primary code and reproducibility · 2026-10-31T00:00:00+13:00. Open test suite, workloads and documented limitations; single-node scope. - [Jepsen finds 96 issues in tested versions of Orkes's ParticleDB](https://runtimewire.com/article/jepsen-particledb-96-issues-orkes-full-acid) — RuntimeWire · independent specialist reporting · 2026-10-31T00:00:00+13:00. Independent report on Jepsen findings and Orkes claim that newer builds address issues.