⏱️ Reading time: 8 min
ParticleDB promised to be “Full ACID” with 159,000 transactions per second on its site’s homepage. Jepsen, the consultancy Kyle Kingsbury runs to tear apart distributed databases with chaos testing, found 96 correctness bugs across versions 1.1.4 through 1.1.18.11.rc-22 of the ParticleDB database. Most of these bugs showed up with a single server, a single client, and zero network failures.
📑 En este artículo
The report, published on October 31, 2026 and funded by Orkes, the company behind the engine, is a typical Jepsen analysis: it mixes comical findings (partially invisible rows that couldn’t be deleted, dropped tables that reappeared distorted) with serious ones, such as lost committed writes even under serializable isolation, the strictest level the engine offers.
TL;DR
- Jepsen found 96 bugs in Orkes’s ParticleDB database between versions 1.1.4 and 1.1.18.11.rc-22
- Serializable mode, ParticleDB’s strictest, allowed internal anomalies and Lost Update
- The groupsync setting lost committed writes despite advertising the same durability as sync
- Orkes released version 1.1.19-rc.13 and claims to have fixed all remaining bugs
- Its own homepage promised “Full ACID” even though the text below it described snapshot isolation
What the ParticleDB Database Is
The ParticleDB database is a multimodal engine Orkes built for AI workloads: it combines transactional SQL, key-value storage, vector search, and live analytics through user-defined functions called Particles. Written in Rust, it exposes Postgres, Redis, gRPC, and HTTP2 protocols to integrate with existing systems.
The stated goal is to replace the typical patchwork of caches, queues, and separate stores that today’s AI applications use. Orkes claims ParticleDB is orders of magnitude faster than Postgres while keeping the same transactional safety guarantees.
What Happened
Orkes hired Jepsen to audit ParticleDB’s refactored versions ahead of a wider release. The result was 96 issues, ranging from the mundane (server crashes, deadlocks, data loss) to the downright strange: partially invisible rows that couldn’t be deleted, WHERE 4 = 5 queries that still returned rows, dropped tables that reappeared in a different shape, columns swapped with each other, and strings that turned into integers.
Most of those 96 cases didn’t need a cluster under stress: a single server, a single client, and no network failures were enough to reproduce them. By version 1.1.18.11.rc-22, Orkes had fixed all but ten of the issues. But those ten included the most serious ones: ParticleDB was still losing committed writes during normal operation with occ, its default transaction mode, and allowed internal anomalies and Lost Update even with serializable, the strongest setting available.
Orkes has already responded. According to Jepsen’s own report, the company released version 1.1.19-rc.13 and says it fixes all the issues that were still open.
Context and History
Orkes didn’t build ParticleDB as a standalone product. The company runs Conductor, a workflow orchestration platform that originally stored its state in Redis and Postgres. To improve performance, Orkes decided to write its own database instead of continuing to combine two separate engines.
ParticleDB version 1.0.0 had a limited feature set, built specifically for Conductor’s queries, and was deployed as the backend for some production clusters. Several Orkes customers followed the same path. Before a wider public release, Orkes did a major refactor: it added its own wire protocol, more data types, and additional OLAP queries, and quietly shipped those versions on particledb.ai. Jepsen started testing exactly those refactored versions, starting with 1.1.4.
One detail the report makes clear: ParticleDB also offers a replicated cluster using the Raft consensus protocol, but that feature is only available in enterprise cloud deployments. The builds Orkes handed to Jepsen didn’t support replication, so everything analyzed corresponds solely to single-node behavior.
The Mechanism Behind the Bugs
ParticleDB’s homepage claimed to be “formally verified” with a TLA+ specification. During the collaboration with Jepsen, however, no TLA+ specification was actually available, so it’s unclear what properties it would have proven or whether they described the real ParticleDB.
Most SQL engines control a transaction’s isolation level with the SET TRANSACTION ISOLATION LEVEL statement. ParticleDB either ignores it or rejects it. Sometimes it tells the user to use READ COMMITTED, a relatively weak level; other times it accepts a request for a different level and silently ignores it, without any warning.
Instead, the actual isolation level depends on a startup flag, --txn-mode, with four documented modes:
| Mode | Behavior | When to use it |
|---|---|---|
| fast | No locks; commits on write | Bulk loads, single-writer benchmarks |
| occ (default) | Overlay plus OCC validation on commit | General OLTP, meant to be safe under concurrency |
| zero-copy-occ | Partition-pinned OCC; single-partition transactions avoid cross-partition coordination | High-throughput OLTP over partition-affine workloads |
| table-2pl | Exclusive table locks on first touch | Strictest serialization, simple semantics |
The problem is that the documentation never explained what each mode formally guaranteed. Did fast correspond to Read Atomic, Read Uncommitted, or something else? Jepsen couldn’t fully confirm it either for occ, the mode any new installation uses by default.
The same confusion shows up with Write-Ahead Log durability. ParticleDB offers three tactics: sync does an fsync on every commit, groupsync batches several transactions into a single fsync, and nosync doesn’t do an fsync at all. The transaction engine’s documentation says sync offers “higher durability” than groupsync.
$ particledb start --help
--txn-mode groupsync # "COMMIT waits for flush"But the command-line help claims groupsync guarantees “COMMIT waits for flush,” and Orkes’s internal operations guide agrees: according to that document, groupsync offers “the same durability as sync.” Three official sources, three different versions of the same guarantee.
⚠️ Heads up: ParticleDB’s homepage literally said “Full ACID. 159K TPS.” and, right below it, the text described “snapshot isolation,” an isolation level that by definition isn’t fully serializable.
Impact and Analysis
For teams evaluating the ParticleDB database for production, the report is a clear warning sign. It’s not that ParticleDB doesn’t work: most of the 96 bugs were already fixed by the last version tested. The problem is that the ones left over affected exactly the default mode (occ) and the mode that, in theory, offers the most guarantees (serializable).
Jepsen notes that Orkes itself funded the study, following Jepsen’s ethics policy, which requires publishing the results without filtering out negative findings. That gives the report credibility, though it also explains why Orkes responded so quickly with a new version.
The study’s most important limitation is that it only covers single-node behavior. ParticleDB sells Raft-based replication for its enterprise cloud customers, but that part of the system was never tested because the builds handed to Jepsen didn’t support it. Any team planning to run a replicated cluster in production should request a separate audit before trusting that layer.
What’s Next
Orkes has already released version 1.1.19-rc.13 and maintains that it fixes all the bugs that were still open when the report closed. Jepsen doesn’t independently confirm that claim in the published document, so for now it’s Orkes’s word against its own earlier results.
For any team already using or evaluating ParticleDB, the practical step is to choose --txn-mode with the same care the project’s own documentation recommends: the published best practice warns that the mode “changes correctness and performance more than the SQL text does,” so it’s not a good idea to leave it at the default without understanding what it covers.
Try it yourself: before putting the ParticleDB database into production, run your own concurrency test suite with the --txn-mode you plan to use and compare the result against Jepsen’s report at jepsen.io.
Frequently Asked Questions
Does ParticleDB really comply with ACID?
Not fully in the audited versions. Jepsen found lost committed writes in the default mode and anomalies even under serializable, the strictest level ParticleDB offers.
Which ParticleDB transaction mode is safest?
According to the documentation, table-2pl offers the strictest serialization with exclusive table locks, though Jepsen’s report doesn’t confirm that any mode is completely bug-free across all the versions tested.
Does ParticleDB support replication?
Yes, through the Raft protocol, but only in enterprise cloud deployments. Jepsen didn’t evaluate that layer because the builds it used didn’t include it.
What is Orkes, and why did it build ParticleDB?
Orkes is the company behind Conductor, a workflow orchestration platform. It built ParticleDB to replace the Redis-and-Postgres combination Conductor used and to improve performance.
Have the bugs Jepsen found in ParticleDB already been fixed?
Orkes says version 1.1.19-rc.13 fixes all the issues that were still open when the report closed, though Jepsen doesn’t independently confirm this in the published document.
References
- Jepsen: ParticleDB 1.1.4: Kyle Kingsbury’s original report with the 96 bugs found.
- Jepsen on GitHub: the framework and methodology Jepsen uses to audit distributed databases.
- Raft Consensus Algorithm: the replication protocol ParticleDB offers in its enterprise cloud.
- Conductor OSS: Orkes’s orchestration platform that originated ParticleDB’s development.
- ACID (Wikipedia): definition of the atomicity, consistency, isolation, and durability properties.
📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Featured image: Foto de Markus Stickling en Unsplash
Did it work for you? Got a different error? Say so below: questions get answered and help the next reader.
Leave a comment
0 Comments