ParticleDB Jepsen Report: What Was Tested and What Orkes Says It Fixed

Jepsen published an October 31 report identifying 96 issues in ParticleDB, Orkes’ database for AI agents. Orkes says a newer version fixes all reported issues. For developers evaluating agent infrastructure, the important distinction is between the versions independently tested and the fixes subsequently reported by the vendor.

What the ParticleDB Jepsen report tested

The Jepsen report covers versions 1.1.4 through 1.1.18.11.rc-22. Orkes funded the evaluation. Testing covered single-node behavior, not replicated clusters.

By the final tested version, all but ten issues appeared resolved. Jepsen still observed committed writes disappearing during normal operation in the default occ transaction mode, alongside transaction anomalies in serializable mode. Many problems required neither hardware failure nor multiple servers.

That scope matters. The report concerns the refactored 1.1.x releases, rather than establishing that every earlier Conductor deployment experienced these failures.

What Orkes says is fixed

In its ParticleDB announcement and response, Orkes acknowledges the findings and says all identified issues have been addressed as of version 1.1.19. Jepsen identifies the subsequent release as 1.1.19-rc.13.

A vendor-reported fix is different from an independently verified retest. The published evaluation does not establish that the newer release passes those tests. Equally, its results should not be presented as proof that the latest version retains every earlier bug.

For a prospective user, the next useful evidence would be a reproducible run against the exact release being considered, with its transaction settings recorded. An issue count alone does not answer that deployment question.

Why an agent database needs more than useful interfaces

ParticleDB combines relational SQL, key-value operations, vector search and live analytics. Its Particles feature brings application code close to stored data. Orkes currently supports Python Particles and describes PostgreSQL and Redis client interfaces alongside native APIs.

The appeal is understandable. An agent can need both retrieved context and operational state during the same task. Keeping those capabilities together could reduce the synchronization work between separate systems.

But there is a different requirement underneath that convenience. Consider a workflow that records whether an external action has completed. If that record is lost, retry logic may repeat the action. A more capable model cannot reconstruct a reliable execution history simply by reasoning harder.

This is why teams should evaluate retrieval quality and state correctness separately. A good search result does not demonstrate durable writes, and accepting a familiar client connection does not by itself establish equivalent database behavior.

What developers should check next

For an evaluation, I would start with the application's invariants: which records must never disappear, which updates must happen together, and which actions must not be repeated. Then test those properties under concurrency and recovery, using the intended release and configuration.

Combining several data workloads can simplify an architecture, but it also concentrates responsibility in one engine. The useful milestone is reproducible correctness for the workload, followed by performance measured under those same guarantees.

That is the question worth following as ParticleDB's fixes are evaluated: whether the operational evidence catches up with the promise of a simpler agent stack.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders explain complex infrastructure and turn product updates into clear stories that developers can understand and share.

Book a 30-minute call.