Jepsen found 96 ParticleDB bugs — and the default transaction mode still lost writes

Jepsen’s Oct. 31 analysis of ParticleDB does not read like a broad warning about database hype. It is a version-specific indictment of a system that Orkes marketed as “Full ACID,” while Jepsen says the tested builds were not yet fit to carry that promise.

The report covers ParticleDB 1.1.4 through 1.1.18.11.rc-22 and says it found 96 issues across those versions. Jepsen’s summary on the analysis page says the claims of “Full ACID” were “somewhat premature.” A later Orkes blog post now says ParticleDB 1.1.19 addresses all identified issues, but that is the vendor’s claim, not an independent retest in the material available here. Sources: https://jepsen.io/blog/2026-10-31-particledb-1.1.4 and https://orkes.io/blog/particledb-database-built-for-ai-agents

What makes the report uncomfortable is not just the number of failures. Jepsen’s write-up, as summarized in contemporaneous coverage, says many of the problems appeared on a single healthy node with no injected faults. That means the failures were not limited to some rare distributed-systems disaster. In the tested builds, the database could misbehave under ordinary operation. Source: https://runtimewire.com/article/jepsen-particledb-96-issues-orkes-full-acid and https://dev.to/axrisi/particledbs-jepsen-report-lenovos-fingerprint-usb-stick-karpathys-hackertube-and-the-linux-tcp-4nbc

What Jepsen says it actually tested

Jepsen says it evaluated ParticleDB as a multi-model database built for and with AI. Orkes’s own current product page describes ParticleDB as combining transactional SQL, a key-value store, vector search, live analytics, and user-defined code in a single Rust engine. The quickstart and docs show the system being used with SQL tables, Redis-style key/value commands, vector search, and Python “Particles.” Sources: https://particledb.ai/ and https://orkes.io/blog/particledb-database-built-for-ai-agents

That context matters because the system is aimed at applications where metadata integrity is the point: agent state, retrieval records, counters, and transactional updates. If those layers can go wrong, a vector index sitting on top does not rescue the application.

Jepsen’s public analysis page is dated Oct. 31, 2026. Its summary says:

“We tested versions 1.1.4 through 1.1.18.11.rc-22 and found that ParticleDB’s claims of ‘Full ACID’ were somewhat premature.”

The same page says the work was done with Orkes and that most issues were resolved by the end of the collaboration, with Orkes believing the remaining issues had been fixed by 1.1.19-rc.13. Source: https://jepsen.io/blog/2026-10-31-particledb-1.1.4

The failures were not subtle

The available reporting lists failures that go beyond a weakened isolation guarantee. Examples cited in the coverage include:

• WHERE 4 = 5 returning rows with primary key 5
• WHERE TRUE matching nothing
• an UPDATE leaving multiple rows with the same primary key
• rows from dropped tables reappearing in mangled form
• aborted transactions committing, or appearing to fail while their effects remained visible

Those examples suggest the problem was not just contention under load. They point to basic SQL semantics breaking down. Source: https://dev.to/axrisi/particledbs-jepsen-report-lenovos-fingerprint-usb-stick-karpathys-hackertube-and-the-linux-tcp-4nbc

The most operationally important finding, though, is the one that affects users even when nothing is partitioned or crashed: the default occ transaction mode reportedly lost committed writes during normal operation. RuntimeWire’s summary of the Jepsen report says that was the central consequence for users evaluating the system as a transactional store. Source: https://runtimewire.com/article/jepsen-particledb-96-issues-orkes-full-acid

Why the transaction mode dispute matters

One of the sharpest disagreements in the reporting is not about a benchmark number but about how users were told to think about the product.

A contemporaneous summary says ParticleDB’s actual isolation behavior depended on a startup flag, --txn-mode, and that the database ignored or rejected normal SET TRANSACTION ISOLATION LEVEL requests, sometimes telling users to settle for READ COMMITTED. Another report says that after the testing, Orkes labeled the transaction modes experimental and described the tested versions as unsupported pre-release builds, while Jepsen pointed out that the Docker install page showed users how to deploy those versions for production. Sources: https://x.com/NewsTongueX/status/2116630564727881973 and https://dev.to/axrisi/particledbs-jepsen-report-lenovos-fingerprint-usb-stick-karpathys-hackertube-and-the-linux-tcp-4nbc

That is the key practical tension for prospective users. If the guarantee is controlled by a startup flag rather than the SQL contract your application issues at runtime, it is easy to believe you have stronger isolation than you actually do. And if the vendor later calls the same builds experimental, the production guidance around those releases becomes part of the story, not a footnote.

What the vendor now says

Orkes’s current ParticleDB blog post says it worked through the issues and that “as of ParticleDB 1.1.19, we report that all identified issues have been addressed.” Its product page also frames ParticleDB as a single engine for AI agents, with SQL, key-value, vector, analytics, and programmable logic in one place. Sources: https://orkes.io/blog/particledb-database-built-for-ai-agents and https://particledb.ai/

That is a meaningful update, but it is still a vendor statement. The captured material here does not include an independent retest of 1.1.19 or later. So the safest conclusion for users is narrower than “ParticleDB is fixed”: the tested builds had serious safety and correctness defects, Orkes says later releases addressed them, and anyone considering the product now should verify the exact version and transaction mode they plan to run.

What vector-database users should verify now

For teams evaluating ParticleDB or any vector-oriented database that also promises transactional behavior, the lesson is specific rather than philosophical.

Verify the invariants that matter to your workload on the exact build you intend to deploy:

1. Confirm the default transaction mode and whether it can be changed safely.
2. Test whether SQL isolation-level requests are honored or ignored.
3. Verify write durability across process restarts and forced kills.
4. Reproduce uniqueness, primary-key, and update invariants with your own schema.
5. Check whether vector search depends on the same transactional core as metadata writes.
6. Read the release notes and docs for terms like experimental, unsupported, or pre-release.

Jepsen’s report, as captured here, says the tested ParticleDB versions failed those basics often enough to justify halting deployment on the affected builds. Orkes says 1.1.19 fixes the issues. Until an independent retest says otherwise, users should treat that as a reason to re-verify, not to assume the risk is gone.

The practical takeaway for AI systems is simple: retrieval is only trustworthy if the records underneath it stay intact. ParticleDB’s Jepsen report says the tested versions did not reliably do that.

Sources: https://jepsen.io/blog/2026-10-31-particledb-1.1.4, https://orkes.io/blog/particledb-database-built-for-ai-agents, https://particledb.ai/, https://runtimewire.com/article/jepsen-particledb-96-issues-orkes-full-acid