The Nightly Build.
Feature

Jepsen finds ParticleDB’s default mode losing committed writes among 96 issues

In versions 1.1.4 through 1.1.17 of ParticleDB, advertised as “Full ACID. 159K TPS.”, WHERE 4 = 5 returned the row with primary key 5.

5 min read2026-11-01

Guarantees tested one node at a time

Orkes advertised ParticleDB, a Postgres-compatible database, as “Full ACID. 159K TPS.” and as “formally proven” with TLA+, wording that Jepsen’s report quotes from the home page.1 On 2026-10-31 Jepsen reported 96 issues from tests of versions 1.1.4 through 1.1.18.11.rc-22 and wrote that the Full ACID claim was “somewhat premature.” The default transaction mode, occ, lost committed writes in normal operation. The TLA+ claim could not be checked, because no specification was available.1

Orkes, the vendor, funded the analysis, which Jepsen says it conducted under its ethics policy. Every test ran on a single node, because the builds Orkes supplied did not support replication.1

Four of six claims met a measured failure

Each row is one advertised guarantee, in the words the report prints, and each cell to its right is what Jepsen recorded against it. Orkes has since rewritten the home page and documentation pages the report quotes, so the report is now the record of that wording.1

Advertised wording against Jepsen’s result, with the anomaly defined where it first appears. The last two rows quote, in part or in full, an operator guide Orkes did not publish. Report sections, by row: 3.8.7, 3.8.8 and 3.8.14, 1.1, 3.8.16, 1.1, 3.2.3.1
Advertised Jepsen result Build and mode
“Full ACID. 159K TPS.” Committed writes lost; aborted reads (G1a), where a committed transaction reads a write from an aborted one;2 Lost Update, where a transaction overwrites a concurrent committed write it never observed.3 1.1.4 through 1.1.18.9, every mode, no faults
“snapshot isolation” G-single, where a transaction observes one effect of another but misses a second effect of it (#73).4 Read skew (A5A), where it both observes and fails to observe the other’s effects (#106).5 G-single in rc-1 through rc-22; A5A with table-2pl in rc-18
“formally proven” with TLA+ Could not be checked. No specification was available. None tested
occ is “Jepsen-safe” Acknowledged writes discarded on a healthy node: 31 lost among about 20,000 keys, every few minutes (#110). rc-18 through rc-22, both interfaces
groupsync gives the “same durability as sync” A conflict between documents, not a measured failure. The public docs said sync had “stronger durability,” and Jepsen reports no comparison. Orkes’s current docs say the two give the same guarantee.6 Documentation
Prepared statements “all work as expected” Any prepared statement through the Postgres JDBC driver raised an exception, leaving the database “essentially unusable” (#2). 1.1.4 through 1.1.18.9; appeared fixed by rc-1

“Jepsen-safe” was Orkes’s own label. Jepsen printed it and wrote that, since it evaluates safety against documentation and marketing claims, it was not clear how to interpret the term.1

WHERE 4 = 5 returned the row with primary key 5

Jepsen’s example is a table t with columns a, the primary key, and b, holding rows 4 | 5 and 5 | 6. In versions 1.1.4 through 1.1.17, ParticleDB “aggressively interpreted WHERE something = x as a primary-key lookup of x, regardless of the value of something.”1 The query in the diagram therefore asked for key 5 and never compared the 4.

SELECT * FROM t WHERE 4 = 5; EXPECTED 4 = 5 is false for every row, so the filter keeps nothing PARTICLEDB 1.1.4 THROUGH 1.1.17 WHERE something = x is read as a primary-key lookup of x = 5 constant filter RESULT (0 rows) lookup a = 5 a (primary key) b 4 5 5 6 returned
Fig. 1 · Jepsen’s example for issue #18: table t holds rows (4, 5) and (5, 6). The right lane follows the report’s description of the rewrite and is drawn for this article, not copied from ParticleDB’s planner.1

The example is a single statement with no concurrent transaction. Version 1.1.18.4 stopped treating every equality as a key lookup. A related fault appeared only inside a transaction: in 1.1.4 through 1.1.18.8, SELECT * FROM t WHERE TRUE returned no rows (#35), and it seemed improved in 1.1.18.9.1

Ten issues survived to rc-22

Jepsen wrote that by 1.1.18.11.rc-22 all but ten of the 96 issues appeared resolved.1 The chart places seven findings on the builds Jepsen tested, four of them among the ten. A bar spans the builds where the behavior appeared, and a bar that reaches rc-22 was still open when testing ended.

Finding 1.1.18.11 1.1.19 1.1.4 1.1.17 1.1.18.8 1.1.18.9 rc-1 rc-18 rc-22 rc.13 #18 WHERE 4 = 5 fixed by 1.1.18.4 #35 WHERE TRUE in txn improved in 1.1.18.9 #2 prepared statements appeared fixed by rc-1 #73 G-single #110 lost committed writes #109 stale read #107 Lost Update after kills Resolved in a later tested build Open at rc-22 Orkes says fixed in rc.13, untested
Fig. 2 · Builds are ordered, not to scale. Issue #35 appeared inside a transaction. Issues #107 and #109 were reproduced under strict-serializable at rc-18, a mode the report says may have been renamed serializable in rc-22, where its Discussion says both still occurred.1

Stale read, the behavior behind #109, is a read that fails to observe an earlier completed write, which strict serializability forbids.7 Jepsen saw it roughly every 300,000 transactions at rc-18. Process kills produced Lost Update under the same mode (#107).1

Jepsen has not evaluated any build after rc-22. It recommended that users halt further deployment of ParticleDB and migrate to other databases as soon as possible. Orkes told Jepsen the issues likely came from an extensive refactor in spring 2026 and that customers who stayed on an earlier version were likely unaffected.1 Orkes’s own post says: “As of ParticleDB 1.1.19, we report that all identified issues have been addressed.”8 Jepsen’s report names the build as 1.1.19-rc.13.

Sources

  1. Jepsen · ParticleDB 1.1.4 (Kyle Kingsbury, 2026-10-31)
  2. Jepsen · G1a (Aborted Read)
  3. Jepsen · P4 (Lost Update)
  4. Jepsen · G-single
  5. Jepsen · A5A (Read Skew)
  6. ParticleDB · operations modes page, durability section
  7. Jepsen · Stale Read
  8. Orkes · blog post on ParticleDB and the Jepsen findings, “What we learned from Jepsen”