Jepsen published its analysis of ParticleDB on October 31. Kyle Kingsbury tested versions 1.1.4 through 1.1.18.11.rc-22 and filed 96 issues. All but three of them appeared on a single healthy node with no faults injected. The default transaction mode lost committed writes during normal operation. The report ends by recommending that users halt deployment and migrate to another database.

Orkes, the company behind the managed version of the Conductor workflow engine, paid for the research. That is how Jepsen engagements work, and Orkes deserves credit for letting the report go out. The funding doesn't soften the result.

What the tests found

ParticleDB is a closed source database written in Rust. Orkes pitches it as one engine for transactional SQL, a key-value store, vector search, live analytics, and stored procedures it calls Particles. It speaks the Postgres and Redis wire protocols. When the engagement began, the home page said "Full ACID. 159K TPS." and described the system as formally proven with TLA+. Jepsen asked for the TLA+ specification. None was available.

The SQL layer failed before concurrency entered the picture.

SELECT 5 WHERE FALSE;         /* returned 5 */
SELECT * FROM t WHERE 4 = 5;  /* returned the row with primary key 5 */

NOT NULL and UNIQUE constraints were ignored. An UPDATE could create duplicate primary keys, or null ones. Floating point comparisons in a WHERE clause inside a transaction matched nothing. Inserts ignored column order. Strings came back as 8 bit integers. Infinity could be written but not read, and NaN turned into 0.0. A dropped table resurfaced with altered data, and a value stored as 18.83 came back as 19.

Some rows could not be deleted. Update an integer column with a double and the row became permanent. Fixed width CHARACTER(n) values were immutable. Deleted rows kept showing up in aggregates. Jepsen's term for these is zombies, and the report lists seven separate ways to create one.

Transactions were worse. A nested BEGIN discarded the outer transaction's writes. Aborted transactions could commit anyway, or leak their effects. Tables with text primary keys were mostly invisible inside transactions. The mode named table-2pl, which the docs called the "strictest serialization," showed read skew and stale reads, and through 1.1.18.4 most of its transactions took 10 to 30 seconds and then failed. The default mode, occ, which the docs called "safe under concurrency," allowed lost updates and G-single anomalies. In release candidates 18 through 22, Jepsen counted 31 lost writes across about 20,000 keys in four transaction modes, including the one named serializable-ssi.

Then the durability tests. Flipping two bits in a write ahead log made 44 list elements vanish, and the server started anyway. Shuffling 13 chunks of four kilobytes each, about 10% of a WAL file, produced a log line saying ParticleDB was "starting fresh" and a WAL of zero bytes. Every record gone, no error.

The documentation and the claims

"Full ACID" sat on the same home page as "snapshot isolation," which is not full isolation. The operator guide said the groupsync setting had the same durability as sync. The main docs said sync was stronger. The Java SDK was listed on Maven, but neither the JAR nor the source could be found, and the client docs pointed at dependency coordinates that did not exist. The stored procedure docs included a contact address that was made up. Prepared statements, which the docs said worked with unmodified Postgres clients, crashed the JDBC driver.

After testing finished, Orkes updated the docs to label every transaction mode "experimental." Jepsen could find no earlier version of the docs carrying that label. Orkes also published a release history that calls 1.1.4 through 1.1.18.11.rc-22 "unsupported pre-release builds." The Docker page had described those same builds as suitable for production. And nobody who has read a changelog would mistake 1.1.4 for a release candidate.

Jepsen's suggested warning text for the docs: "This software has lost data and will do so again."

The tests that weren't run

Orkes told Jepsen it had already run Jepsen's public Postgres test suite against ParticleDB, along with SQLancer. That suite failed immediately against 1.1.4. Kingsbury wrote on Hacker News that his understanding was Orkes had asked AI agents to test ParticleDB internally before the collaboration.

The report has a section titled LLM Tradeoffs. It says the LLM tooling repeatedly claimed bugs were fixed when they were not. Orkes engineers could explain the cause and the fix for bugs in Conductor, a codebase their team has worked in for years. They could not explain most of the ParticleDB issues. New builds arrived without changelogs. Kingsbury's summary line is that ParticleDB "was a fractal of correctness errors."

I've run databases in production for most of my career, and I don't much care how the code got written. I care whether anyone ran it. A WHERE clause that matches the wrong row gets caught by the first example test a person writes for a query planner. UNIQUE being ignored gets caught by the second. These bugs did not survive because they were subtle. They survived because the thing that checked for them was the same kind of tool that wrote them, and it reported success.

That is the part that applies beyond Orkes. An agent that writes the code and an agent that writes the tests share the same blind spots. Mutation testing, which Jepsen recommends in the report, is one answer, because it checks whether the tests can fail at all. A human who reads the output of a failing test is another. Neither is new. Both got skipped here, on a product whose home page said it was formally proven.

Where it stands now

By rc-22, all but ten of the original issues looked resolved. Jepsen's verdict was that rc-22 was safer than 1.1.4 and still unsafe. The default occ mode still lost data. The serializable mode still allowed stale reads, and with process kills it allowed lost updates too.

Orkes says in its own post that as of 1.1.19 all identified issues have been addressed, and that it now publishes performance numbers only with a reproducible result bundle. Jepsen has not tested 1.1.19. Orkes also removed the txn-mode flag and renamed two of the modes, and Jepsen could not tell from the docs whether the other modes were removed or only renamed. A member of the ParticleDB team said on Hacker News that the company now runs sustained Jepsen workloads daily alongside its own suites.

Replication was never tested, because the builds Jepsen received did not support it. The Redis and HTTP APIs, vector search, materialized views, and multitenant support were out of scope. Jepsen did not reproduce the throughput claim. Over the course of an hour, throughput fell and latency rose.

So the published report covers the single node, no fault, happy path of a database, and that path lost data. The distributed parts, the parts Jepsen is known for breaking, have not been looked at. If you have ParticleDB anywhere near real data, follow the report's advice and move it. If Orkes wants the "Full ACID" line back on the home page, the way to earn it is a second Jepsen engagement against 1.1.19 with replication turned on. My guess is that report, if it happens, finds another dozen issues, and that the honest outcome for Orkes is a database that ships in 2027 with a smaller feature list and a longer test suite.