Jepsen found WHERE 4 = 5 returns a row in ParticleDB, the database that sold 'Full ACID'

ParticleDB's homepage advertised 159K TPS and a TLA+ proof. Jepsen reported 96 issues, then the vendor's own engineer joined the thread.

In brief

Kyle Kingsbury's team tested ParticleDB 1.1.4 and found `WHERE 4 = 5` returning a row, dropped tables coming back with altered values, and acknowledged writes vanishing. The vendor funded the study and fixed most of it in later releases.

A ParticleDB engineer replied that supported modes are now clean. Commenters pointed out that Jepsen's own text says the default mode still lost committed writes.

159K transactions per second, and a snapshot-isolation footnote

The Jepsen analysis covers a multi-model database for AI workloads that combines SQL, key-value, vector search and analytics. The homepage said "Full ACID. 159K TPS", but the text beneath described snapshot isolation. A TLA+ proof was advertised, though no specification was available to testers. Docs disagreed on whether sync or groupsync gave stronger write-ahead-log durability.

Jepsen tested versions from 1.1.4 through 1.1.18.11.rc-22 on single nodes and reported 96 issues. A few examples from the report:

  • WHERE 4 = 5 returned the row with primary key 5, and SELECT 5 WHERE FALSE returned a row.
  • NOT NULL and UNIQUE were ignored at first, and primary keys could be set to NULL.
  • Deleted rows lingered, dropped tables reappeared with altered values, and strings sometimes became integers.
  • Aborted transactions could commit, and write-ahead-log bitflips caused partial data loss.

Orkes, which funded the work, fixed most items in successive releases. By the last tested build Jepsen counted about ten unresolved, including a default occ mode that still lost committed writes. Jepsen recommended that users halt deployment and migrate.

The ParticleDB reply

A member of the ParticleDB team wrote that the company now runs sustained Jepsen workloads daily and has "narrowed the supported transaction modes". Recent runs, he said, found no anomalies in the supported modes that provide isolation guarantees.

How the thread read that answer

"The fact that they then said they addressed the issues, but didn't, is about the biggest red flag imaginable. I would never let any client use this software under any circumstances." — a commenter who once had a database evaluated by Jepsen

He said his own experience working with the Jepsen author was the opposite: a few real bugs, fixed urgently, and a lot of in-house testing before the engagement began.

Incorrect by construction

One commenter offered a frame for why 96 unrelated bugs can still have one cause. Some software is correct by construction, so failures are local bugs. Other software is incorrect by construction and works through luck and workarounds around the flawed design. ParticleDB, he suggested, is the second kind.

A different worry came from a reader who noticed the report's tone growing weary. A dishonest vendor, he suggested, could quote the report's line that Orkes engineers "were able to produce a highly sophisticated database system" on its homepage without the context.

Get breakdowns like this every day

The top Hacker News stories, unpacked — by email, Telegram, or RSS.

Next story · 4 of 11 Read more
🌍Other

Karpathy built a YouTube for the 6,454 videos Hacker News commenters recommended

After a late-night session with YouTube's recommendations, Andrej Karpathy spent a Saturday morning with Claude Opus 5.5 building hackertube.org.

★ 742 · 💬 245 · karpathy.bearblog.dev · 2 min