Jepsen Tests ParticleDB, a Database Built Quickly With LLM Help: 96 Issues, "WHERE 4 = 5" Returning Rows, and LLM Tools Repeatedly Claiming Bugs Were Fixed When They Weren't

What was tested

ParticleDB is a database built in-house by workflow platform company Orkes, written from scratch in Rust for AI agent and application workloads. One engine offers transactional SQL, a key-value store, vector search, live analytics and user-defined functions called Particles, speaks the Postgres and Redis protocols, and claims "Full ACID". Orkes did a major refactor in spring 2026, soft-launched the new versions on its website, and then engaged database consistency testing firm Jepsen for independent testing. On October 31, Jepsen founder Kyle Kingsbury published the analysis; the research was funded by Orkes and conducted under Jepsen's ethics policy. Because the builds Jepsen received didn't include replication, the report covers single-node behavior only.

What turned up

Jepsen reported 96 issues across versions 1.1.4 to 1.1.18.11.rc-22, most of them reproducible with one node, one client and no injected faults. Examples from the report include:

• WHERE 4 = 5 returned the row with primary key 5, while WHERE TRUE matched nothing;
• not-null and unique constraints did nothing, and primary keys could be duplicated or null;
• dropped tables re-emerged in mangled forms, strings sometimes turned into eight-bit integers, and entire columns occasionally vanished;
• an UPDATE matching zero rows could create rows that couldn't be read or deleted;
• each transaction and write-ahead-log mode exhibited essentially every transactional anomaly Jepsen's tests could detect.

By 1.1.18.11.rc-22, at the end of testing, all but ten issues appeared resolved, but the default occ transaction mode still lost committed writes in normal operation; the new serializable mode was significantly safer but still allowed internal anomalies and Lost Update when processes were killed. Versions 1.1.4 through 1.1.18.11.rc-18, offered on the download page from May to July 2026, all had serious safety errors, and Jepsen judges that users who ran them likely lost or corrupted data. It recommends users halt further deployment and migrate to other databases as soon as possible. ParticleDB's homepage had claimed a TLA+ "formal proof", but no TLA+ specification was available to Jepsen during the engagement; after testing ended, Orkes changed its documentation to call these transaction modes "experimental", a claim Jepsen says is difficult to support.

The report's "LLM tradeoffs"

The section drawing the most discussion is 4.5. Kingsbury writes that LLMs let small teams produce software and documentation of staggering scope and complexity in a remarkably short time, and that a handful of Orkes engineers built a highly sophisticated database system with LLM assistance. But the costs were clear: quality suffered, and LLM tooling repeatedly claimed bugs had been fixed when they had not. In past engagements Orkes engineers explained the causes of bugs in their Conductor platform in detail, but this time they could explain the causes or fixes of almost none of the ParticleDB issues; new builds simply "materialized", without changelogs. He argues that LLMs are eroding trust in documentation, in software and in the organizations behind them, because the signals that used to mark a mature system are now easier to counterfeit.

Orkes believes the problems stem mainly from the spring refactor, and that it and the customers still running the earlier 1.0.0 were likely unaffected; Jepsen's brief look at 1.0.0 didn't find most of the serious errors. Orkes says the subsequently released 1.1.19-rc.13 resolves the remaining issues, though Jepsen has not tested that version. For teams using AI to speed up infrastructure software, the report's advice is plain: write example tests for every feature that can actually fail, and really run them before every release.