Can You Trust an AI-Built Database? Jepsen Found 96 Bugs in ParticleDB

Jepsen found 96 bugs in ParticleDB, an AI-focused database built with LLM help, and told users to stop deploying it. Here's what broke and why it matters.

TheTechLane cover on a tomato-red dotted background with a large TL logo ringed in yellow, a tilted black code strip reading SELECT * FROM t WHERE 4 = 5 returning 1 row, the headline Can you trust an AI-built database?, and 96 tally marks above the label 96 issues, 1 verdict: halt deployments.

Database testing outfit Jepsen has told users to "halt further deployment of ParticleDB and migrate to other databases as soon as possible" after finding 96 issues in the AI-focused database, which its makers built with help from large language models. The October 31 report reads like a warning label for the whole industry.

Here's what you need to know:

  • Jepsen tested ParticleDB 1.1.4 through 1.1.18.11.rc-22 and logged 96 issues, from lost writes to WHERE 4 = 5 returning rows.

  • All but three of those issues showed up on a healthy, single-node server with no injected faults.

  • Jepsen says "LLM tooling repeatedly claimed that bugs had been fixed when, in fact, they had not."

  • Maker Orkes says version 1.1.19-rc.13 fixes the remaining issues, but Jepsen hasn't tested anything after rc-22.

  • The work was funded by Orkes itself, under Jepsen's ethics policy.

What Happened

ParticleDB is a multi-model database from Orkes, the company behind the Conductor workflow orchestration platform. It's written in Rust, speaks the Postgres and Redis protocols, and pitches transactional SQL, key-value storage, vector search and live analytics in one engine "with a special focus on AI agents and applications."

In Jepsen's ParticleDB 1.1.4 analysis, published October 31, Kyle Kingsbury tested single-node builds on Debian 13 and found 96 issues "ranging from the pedestrian (crashes, deadlocks, data loss, etc.) to the piquant." Some highlights:

  • SELECT * FROM t WHERE 4 = 5 returned the row with primary key 5.

  • NOT NULL and UNIQUE constraints were ignored in early builds, leaving rows that COUNT(*) could see but SELECT * could not.

  • Strings were sometimes returned as 8-bit integers, and primary keys could become null.

  • In later builds, out of roughly 20,000 keys in one test, 31 lost acknowledged writes in normal operation.

UML sequence diagram of three ParticleDB bugs from Jepsen's October 31, 2026 report: in versions 1.1.4 to 1.1.17, SELECT * FROM t WHERE 4 = 5 on a table holding rows (4, 5) and (5, 6) returned the row (5, 6) instead of no rows (bug 18); inserting NULL into a BOOLEAN NOT NULL column was accepted, after which SELECT * returned 0 rows while COUNT(*) returned 1 (bug 8); and in rc-18 to rc-22 an append test over about 20,000 keys had its writes acknowledged, but 31 keys later turned out to have lost acknowledged writes (bug 110)

Three of Jepsen's 96 ParticleDB findings, query by query

The marketing didn't match. Jepsen says ParticleDB's home page claimed "Full ACID. 159K TPS." and a TLA+ proof, yet no TLA+ specification was available during testing. It also advertised being "1087x faster than PostgreSQL," but Jepsen saw nothing near that and recorded throughput declining over an hour.

Jepsen's verdict on the documentation was blunt: it was "riddled with omissions, inconsistencies, and confabulations." The Java client docs referenced dependency coordinates that didn't exist, and the stored procedure docs even fabricated an email address for the report's author.

Orkes told Jepsen the problems likely came from a major spring 2026 refactor, and that it and its customers kept running the older 1.0.0, which Jepsen found far less affected in a brief check. At least builds 1.1.4 through 1.1.18.11.rc-18 were on the download page from May through July 2026. The ParticleDB releases page now labels 1.1.4 through rc-22 "unsupported pre-release builds" and lists 1.1.19-rc.16 as current.

Why It Matters

This isn't just one young database having a rough launch. Jepsen used the report to call out something bigger: what happens when LLMs write most of a system that's supposed to guarantee correctness.

"With LLM assistance, a handful of engineers at Orkes were able to produce a highly sophisticated database system," the report says. "However... Quality suffered: ParticleDB was a fractal of correctness errors."

Jepsen also says Orkes "seemed unable to explain the causes or resolutions of nearly every issue," and new builds arrived without changelogs. Its sharpest line: "Why did it stop in 1.1.18.11.rc-1? Perhaps no one knows. With LLMs, perhaps no one needs to."

The trust problem is the real story. Jepsen warns that "the signals we used to rely on as markers of a mature system are now easier to counterfeit": polished docs, big benchmark numbers, client libraries in a dozen languages. ParticleDB had all of that.

The report landed fast with developers too. The Hacker News thread on Jepsen's ParticleDB report had 287 points at the time of writing. And it echoes a pattern we flagged when Cloudflare took over tsrs, a Rust port of TypeScript built by AI agents: agent-written infrastructure can ship astonishingly fast, but it still has to prove itself.

What It Means for Developers

If you run ParticleDB, follow Jepsen's advice first. If you don't, treat this as a checklist for any new database or AI-heavy codebase you're about to trust.

  • Running ParticleDB? Plan a migration. Jepsen recommends checking or rebuilding database state "from more reliable sources, if available."

  • Don't take "fixed" on faith. Orkes says 1.1.19-rc.13 resolves everything, but that claim hasn't been independently tested.

  • Check basics before benchmarks. Insert a NULL into a NOT NULL column. Violate a UNIQUE key. Jepsen asks how anyone adds NOT NULL support "without a test which tries to insert at least one NULL value?"

  • Diff against a reference. Jepsen's roughly two thousand lines of generative tests, running the same random SQL against ParticleDB and Postgres, found a "wealth of bugs." Its open-source ParticleDB test suite on GitHub shows how.

  • Make your agents prove fixes. If an AI tool says a bug is fixed, require a failing test that now passes. Jepsen stresses that seeing a test fail first "validates that the test measures something."

Flowchart of a four-step checklist for trusting a new database or an AI-written fix, based on Jepsen's recommendations: 1, example tests for each feature that fail first and then pass; 2, diff the same random SQL against Postgres for identical results; 3, fault injection to survive crashes, lost fsyncs and corrupt files; 4, an independent test of the exact version you run. Failing any of the first three steps leads to stop, don't ship it, write the failing test; passing step 4 leads to deploy with a rebuild path, while an untested version stays unverified and is pilot only

A four-step trust check before you ship a new database

Prompt-level trust is the same lesson from a different angle, as we saw when a stray AGENTS.md file could hijack Codex and Claude Code.

What's Next

The open question is whether 1.1.19-rc.13, or the current rc.16, actually holds up. Jepsen says it "can prove the presence of bugs, but not their absence," and it hasn't tested either build.

Plenty remains untested, too. Jepsen didn't evaluate replication, the Redis and HTTP APIs, vector search, or multi-tenancy, and it flags Orkes' new Python and Rust stored procedures as worth a closer look.

We couldn't find a public statement from Orkes beyond its updated docs and release notes. And Jepsen's broader question is still open: "In the age of LLMs, what can maintainers do to ensure correct software and accurate documentation?"

FAQ

What is ParticleDB?

It's a Rust-based multi-model database from Orkes that speaks the Postgres and Redis protocols and targets AI agents and applications. Orkes originally built it to back its Conductor orchestration platform.

Is the latest ParticleDB version safe to use?

Nobody independent has said so yet. Orkes claims 1.1.19-rc.13 fixes the remaining issues, but Jepsen tested only up to 1.1.18.11.rc-22 and still recommends halting deployment.

Did AI cause ParticleDB's bugs?

Jepsen doesn't blame a single cause. It points to structural QA gaps, suggests "perhaps engineers entrusted Large Language Models with the work of testing," and says LLM tooling repeatedly claimed fixes that hadn't happened.

Sources

Follow TheTechLane

Keep learning AI, development, and modern developer technologies with TheTechLane.

Learn • Build • Share

Follow @thetechlanehq for more developer guides, tutorials, and practical technology content.