ParticleDB Answered WHERE 4 = 5 by Returning Row Five
Orkes paid for the independent investigation of its AI-focused database. The published test harness exposes both reproducible cases and limits in its own checks.
A database does not need a network partition to give you a bad afternoon. Sometimes asking it whether four equals five is enough.
Jepsen’s two-row reproduction creates integer columns a and b, with a as the primary key. Jepsen writes that affected builds “aggressively interpreted” equality as a primary-key lookup using the value on its right side.
That meant WHERE b = 5 could select the row whose a was five. Even a nonexistent column on the left could lead to a result. The shortcut had skipped the inconvenient business of checking what the comparison meant.
The actual rows make the mistake easy to follow. Jepsen inserted (4, 5) and (5, 6) into columns a and b. A search for b = 5 should select the first row; the affected database returned the second, because its primary key was five. Removing the column name altogether and writing 4 = 5 still fetched that second row. The right-hand value survived the shortcut; the meaning of the left-hand expression did not.
Jepsen says builds 1.1.4 through 1.1.17 showed the issue, with the fix appearing by 1.1.18.4. The wider report describes 96 issues across tested versions. Orkes says a later release fixes the remaining findings; that vendor claim is distinct from a fresh Jepsen test.
Orkes built ParticleDB to combine transactional SQL, key-value operations, vector search, analytics and programmable functions. In its own response, the company says those combined services mean fewer systems and data pipelines to maintain. That is an appealing proposition until one shared engine starts supplying the wrong answer to several kinds of work.
The company paid for the investigation and acknowledges the 96 findings. “All identified issues have been addressed,” Orkes says of version 1.1.19. Jepsen’s report separately names 1.1.19-rc.13 as the subsequent vendor-claimed fix. That distinction prevents a repaired predicate from becoming a certificate for an entire newer release nobody in this report independently evaluated.
The published Jepsen test repository makes the checking more concrete than a collection of spectacular examples. Its compare workload records SQL operations and both databases’ results, including condensed reproductions a developer can paste into a SQL shell. An interactive watcher can submit an edited SQL file to PostgreSQL and to ParticleDB through both its native and PostgreSQL interfaces. It marks the places where the results disagree.
The test authors also disclose limits in that machinery. The README identifies a generator bug that can create partial rather than total row orderings, producing false comparison failures. A checker that admits its own failure modes is more useful than a mysterious red light. It gives another engineer a specific reason to accept, reject or investigate an individual result.
A practical evaluation can borrow that shape without reproducing the entire investigation: retain a tiny input, write down the expected rows, and compare the actual output from the exact build under consideration. If the result is wrong, performance figures can wait. A very fast wrong row still requires somebody to find and repair the consequences.
The next useful evidence is a test of the newer release against the remaining cases. A version number can tell you what to run; it cannot supply the result.