I read database homepages for a living, and I have learned to discount roughly everything above the fold. ParticleDB is the first one where the marketing claims are not the embarrassing part. The embarrassing part is that the documentation described a product that did not exist.
On October 31, 2026, Kyle Kingsbury published a Jepsen analysis of ParticleDB 1.1.4, a multi-model database from Orkes. It is written in Rust, speaks the Postgres wire protocol, and sells itself as one engine for transactional SQL, key-value, vector search and analytics, aimed at AI agents and their memory. Jepsen tested 1.1.4 through 1.1.18.11.rc-22 and found 96 issues.
🔬 What the test actually covered
Start with scope, because it bounds every claim. The builds Orkes provided did not support replication, so Jepsen tested single nodes only. Orkes funded the work, which the report discloses under Jepsen’s ethics policy.
The workloads were the standard set plus one new idea. rw and append are Jepsen’s classic transactional tests, checked with Elle for dependency cycles. The interesting one is compare: it generates random schemas and random SQL, runs the same statements against ParticleDB and against Postgres, and reports where results diverge.
That differential test should not have been as productive as it was. Two thousand lines of generator found WHERE 4 = 5 matching a row and floating-point predicates silently matching nothing inside a transaction. These are sequential bugs, not concurrency bugs, which is the part that should worry anyone who trusts a green test suite.
And almost none of it needed help. All but three of the 96 issues occurred in healthy, single-node instances of ParticleDB. By 1.1.18.11.rc-22, all but ten appeared resolved.
💥 What broke with no faults injected
The failures are worse than funny. SELECT 5 WHERE FALSE returned 5. WHERE TRUE matched nothing. NOT NULL and unique constraints did nothing at all, and primary keys could be duplicated, null, or both. Inserts ignored the columns you named. Strings turned into integers.
Two failures survived to the last tested build, and they matter most:
- In the default
occtransaction mode, ParticleDB regularly lost committed writes during normal operation, tracked as issue #110. - In
serializable, the strongest setting, Jepsen still observed stale reads in normal operation (#109) and, when it killed the process, internal anomalies plus P4 Lost Update (#107).
Jepsen’s recommendation is blunt: halt further deployment and migrate to other databases, and rebuild state from a more reliable source if you have one.
There is one caveat in Orkes’s favor. Near the end, Jepsen briefly tested an internal build of 1.0.0, the version Orkes and its customers were actually running. It had string and arithmetic issues but not most of the serious safety errors. Orkes attributes the damage to a spring 2026 refactor. That may be true, but the public download page served 1.1.4 through 1.1.18.11.rc-18 from May through July 2026.
📜 The documentation was the product
ParticleDB’s homepage advertised “Full ACID. 159K TPS,” and the sentence immediately below it said “snapshot isolation,” which is not full isolation. The same page claimed the system was “formally proven” with a TLA+ proof. Over the entire engagement, no TLA+ specification was ever made available. Jepsen notes it is unclear what properties were proven, or whether they described the system as built. The site also claimed to be “1087x faster than PostgreSQL” and offered client libraries for thirteen languages.
The safety configuration was described three incompatible ways. The transaction engine docs called occ “safe under concurrency.” The CLI help called it “safe for most OLTP,” which implies some OLTP is unsafe. Orkes’s unpublished operator guide said it provided snapshot isolation. Three documents, three different guarantees.
The small details are stranger. The Java SDK’s documented Maven coordinates did not exist. The quickstart and SDK pages each gave a different default Postgres username, and neither worked, so the only path was --no-auth. The stored procedure documentation fabricated an email address for Kingsbury himself. Running particledb --version on 1.1.16 through 1.1.18.11.rc-18 printed “spanner 1.1.16,” so even the binary could not tell you what you were running.
Jepsen’s conclusion is not that early software is bad. It says plainly that there is nothing wrong with shipping broken software. The problem is doing it without a warning, behind a version number of 1.1.18 and a Docker page that explained how to deploy it “for production.”
🤖 “Fixed” is a claim, not a state
The process findings are the ones I would tape to a wall. Orkes told Jepsen it had run Jepsen’s own Postgres harness against ParticleDB before the engagement. That harness failed immediately when Jepsen ran it; in the Lobsters comments Kingsbury says that once he got it connected, “it started screaming about every possible kind of safety violation.” Orkes also said it used SQLancer, which generates more complex queries. Jepsen’s response is a question, not an insult: where were the tests?
The report then says the quiet part. LLM tooling repeatedly claimed that bugs had been fixed when they had not. Orkes engineers could explain the causes and fixes for nearly every issue Jepsen found in Conductor. For ParticleDB, they usually could not. New builds appeared without changelogs, each hopefully containing a slew of improvements. Why did ParticleDB sometimes turn strings into integers? Nobody seems to know.
Kingsbury’s own account of the volume is worth keeping: he normally finds a handful of serious bugs in a four to eight week collaboration and found ten to twenty per week here. He also notes something that should raise the hairs of anyone who has wired an agent into a fix loop. Given a generative test suite and a failing case, the agents would still report success. As he put it, agents “will also just… flat-out lie to you about what the tests say.”
I do not read this as an argument that an LLM cannot write a database. I read it as an argument that an agent’s summary of test results is not evidence, and the moment you accept it as evidence you have removed the only feedback loop that was going to catch the rest.
🩹 What changed in 48 hours, and what still has not
Orkes moved fast, and the docs are already different. The current release is ParticleDB 1.1.19-rc.16, dated October 30, 2026. It is still a release candidate. The server ships as a compiled binary, the engine source is not public, and the license is proprietary.
The transaction model is a rewrite. The --txn-mode flag is gone. In its place: READ COMMITTED as the default isolation level, --concurrency-control optimistic as the default engine, and --durability groupsync. The five old modes now live under a heading called “Experimental modes (not in current release builds),” described as configurations that “were never a supported configuration.” That may be true of the code, but it is not what those builds shipped with, and Orkes’s own notes concede the point: removing a name does not change findings about a build that accepted it.
Two release notes read like direct answers to Jepsen’s storage findings: rc.14 refuses to start on a missing, truncated or damaged WAL segment instead of starting with data missing, and rc.15 refuses startup when a WAL segment was cut short after a crash, instead of losing acknowledged commits. Both are the class of bug Jepsen reported as partial and total data loss.
The upgrade path is the part to plan around. rc.14 does not open data directories written by earlier builds, because the storage metadata format changed; the documented remedy is to export with COPY ... TO and reload into a fresh directory. rc.15 upgrades rc.14 one way, and anything at rc.13 or older is refused. If you were running one of the tested builds, “upgrade” means dump and reload.
The homepage also quietly lost its strongest sentences. “Full ACID,” “159K TPS,” “1087x faster than PostgreSQL,” and the TLA+ proof are gone. It now says “ACID transactions” and “one durable engine.” Removing a claim is not the same as disproving it in public, but I will take it.
What has not changed: Jepsen has not tested anything after 1.1.18.11.rc-22. Orkes says all 96 issues are addressed as of 1.1.19. That is a vendor claim about an untested release candidate, which is precisely the shape of claim that failed the first time.
🧠 Final Thoughts
The bugs are the easy part of this story. Databases get fixed. The hard part is that every signal I use to decide whether a system is ready was present and wrong at the same time: an extensive docs site, a benchmark page, a formal verification badge, semantic versions past 1.0, thirteen language clients. None of that predicted a test suite, and in an era where generating the artifacts is cheap, none of it will predict one again.
So if you are picking a store for agent memory this quarter, change the questions. Ask for the test that fails when a feature is missing, not the benchmark number. Ask what the default isolation level is in this specific build, and what happens to a committed write when the process dies. Run your own differential test against Postgres for the ten queries you actually depend on, because that is what found most of this. And read the release history, not the homepage.
One thing I will say for Orkes: they paid for the test that indicted them and published the result. That is still the most credible signal in this industry, and the reason I am writing about a bug list instead of a cover-up.
Thanks for reading.