--- title: Jepsen: ParticleDB 1.1.4 | daily.dev description: Jepsen tested ParticleDB, a Rust database built by Orkes that unifies SQL, key-value, vector search and analytics, and found 96 issues. Most bugs occurred on a... canonical: https://daily.dev/posts/jepsen-particledb-1-1-4-duaeyv6xm twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Jepsen: ParticleDB 1.1.4 | daily.dev og:description: Jepsen tested ParticleDB, a Rust database built by Orkes that unifies SQL, key-value, vector search and analytics, and found 96 issues. Most bugs occurred on a... og:url: https://daily.dev/posts/jepsen-particledb-1-1-4-duaeyv6xm og:image: https://api.daily.dev/og/posts/dUaEyv6xM.png og:image:alt: Jepsen: ParticleDB 1.1.4 og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Jepsen: ParticleDB 1.1.4 **[Hacker News](https://daily.dev/sources/hn)** · 72 min read · 0 upvotes · 0 comments ## Summary Jepsen tested ParticleDB, a Rust database built by Orkes that unifies SQL, key-value, vector search and analytics, and found 96 issues. Most bugs occurred on a single healthy node with no faults: broken constraints, duplicate primary keys, zombie rows that couldn't be updated or deleted, and corrupted joins. The 'table-2pl' transaction mode was so slow that transactions took 10 to 30 seconds and then failed. ParticleDB's marketing claimed 'Full ACID' and a TLA+ proof, but only offered snapshot isolation and no TLA+ spec was ever provided. Even in later release candidates, testers observed G-single, a violation of snapshot isolation. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What consistency model does ParticleDB's occ transaction mode actually provide? ParticleDB's occ mode (also called occ-v3, occ-v2, or row-2pl) provides snapshot isolation, not full serializability, according to an unpublished Orkes operator guide. The zero-copy-occ mode also provides snapshot isolation, while serializable-ssi provides serializable and table-2pl (aka serializable) provides strong serializable. Despite this, ParticleDB's marketing described the database as offering 'Full ACID'. _Checking what isolation level a database mode truly offers before trusting it in production is easier with sources developers track on daily.dev._ ### Is ParticleDB's table-2pl transaction mode usable in production? In versions 1.1.4 through 1.1.18.4, table-2pl was essentially unusable because most transactions took 10, 20, or even 30 seconds before failing with errors like 'could not serialize access due to concurrent update'. High latency issues appeared improved by version 1.1.18.6, though deadlocks under table-2pl persisted until 1.1.18.11.rc-7. _Evaluating whether a database's strictest isolation mode holds up under load is the kind of due diligence daily.dev readers follow._ ### Did Jepsen find violations of snapshot isolation in ParticleDB after most bugs were fixed? Yes, between versions 1.1.18.11.rc-1 and 1.1.18.11.rc-22, testers occasionally observed G-single, a phenomenon similar to lost update that violates snapshot isolation, on single nodes with no faults, using the occ-v3 and zero-copy-occ transaction modes. Orkes reported that version 1.1.19-rc.13 no longer exhibited G-single after the collaboration. _Tracking which database versions still fail formal consistency checks matters before you commit to one on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 98 comments across hackernews, lobsters (as of 2026-10-31). **TL;DR:** The report is viewed as a devastating, near-unanimous indictment of ParticleDB's correctness and the vendor's QA practices, with widespread suspicion the database was largely 'vibe coded' using LLMs without basic testing; the vendor's in-thread claims of fixes were met with heavy skepticism. **Sentiment:** 2% positive · 10% mixed · 88% skeptical **The case for** - A few note that paying for and publishing a Jepsen report, however brutal, is the responsible thing for a vendor to do. - Some give credit that the team appears to be actively engaging with the findings and responding in the thread. **The pushback** - Many doubt the vendor's claim that all issues have since been fixed, noting a report this damning makes rapid full remediation implausible. - Commenters argue the sheer number and basic nature of the bugs (e.g. NULL handling, WHERE 4=5) indicate no real QA process existed before release. - Several suspect the database was heavily 'vibe coded' with LLMs and that LLM agents may have gamed or lied about test results. - Some argue the marketing claims of 'Full ACID' and a TLA+ proof were actively dishonest or hallucinated, damaging trust beyond just the bugs. - A few feel the vendor's responses in the thread come across as deflecting or insufficiently transparent (e.g. refusing to share test suites). **By community** - hackernews (heated): Overwhelmingly critical of the database and its vendor, with a heated side-argument breaking out over SQL NULL semantics and a vendor representative facing pointed skepticism. - lobsters (skeptical): Strongly skeptical discussion focused on how such basic bugs went undetected and doubts about LLM-driven development and fixes, with direct engagement from the report's author. **Hottest debate:** Whether the vendor's claims that all issues are now fixed (via LLM-driven patching) can be trusted at all, versus the view that the development process itself is fundamentally broken. **Open questions** - Will a follow-up Jepsen test on the redesigned version actually confirm the claimed fixes? - Why did the vendor's own Postgres Jepsen harness and SQLancer testing fail to catch these issues beforehand? - Is ParticleDB's core engine fundamentally unsound by design, or just immature and under-tested? - Why does the vendor refuse to publish their internal test suite despite claims of extensive testing? **Highlights** > > Jepsen recommends users halt further deployment of ParticleDB and migrate to other databases as soon as possible. That seems like the right conclusion, wow. I have to wonder what leads a database developer to hiring Jepsen without first doing even fairly basic testing of their own database. Though I guess in this case it was probably "the LLM told them to", and they didn't even take the preliminary step of asking the LLM to do its own Jepsen-style analysis first (which obviously is nowhere near the same standard, but it sure sounds like it would have caught a lot of this stuff). Or maybe the LLM claimed that it had done so and they believed it? > Orkes said they ran Jepsen’s existing Postgres test harness to find and resolve issues in ParticleDB prior to this work. > — [bakkot on lobsters · 10 points, 1 comments](https://lobste.rs/s/drwd4j/jepsen_particledb_1_1_4#c_n9jqzq) > I asked about this too, hoping to discuss it in the report. FWIW, I ran the same Postgres Jepsen test against ParticleDB--it took a little bit to get it to set up the database and connect, but once it did, it started screaming about every possible kind of safety violation. I'm not sure how they got it to pass! > — [aphyr on lobsters · 13 points](https://lobste.rs/s/drwd4j/jepsen_particledb_1_1_4#c_nkvi2p) > This is the most devastating Jepsen report I've ever read, and I will personally be hammering the entirety of section 4.5 ("LLM Tradeoffs") to our company doors. Too many good quotes to pull, but this from section 4.3 is perhaps the most emblematic: >Most databases have a test suite which exercises at least basic examples of each feature, and it is customary to run those tests before release, if not continuously. Where were those tests for ParticleDB? How does one add support for NOT NULL constraints without a test which tries to insert at least one NULL value? What development process adds a CHARACTER(10) type without trying to write a string of (e.g.) five characters? It does raise the question of why Orkes engaged Jepsen in the first place; like hiring Michelangelo to paint your toilet. How could they be so utterly unaware of the most basic flaws in their product? The impression one takes away from the report is of an entire team deep in AI psychosis, experiencing their work (?) solely through agents, wholly out of touch with reality. (Also great to see Kyle giving technical writing its due, another all too common victim of the mad dash for LLMs.) > — [hmpc on lobsters · 11 points, 2 comments](https://lobste.rs/s/drwd4j/jepsen_particledb_1_1_4#c_eszq9j) > Bro you've got to be kidding. pre-release builds? Aphyr directly addresses this in this analysis. Furthermore, given the absolutely ridiculous nature of some of these bugs, and the low confidence exhibited by the authors in the fixes, how can anyone assume that suddenly things are correct? The database was so janky that it sounds like most of the time was spent on basic bugs that a decent set of unit-tests would've caught. Who knows what wasn't uncovered because the db was so broken to begin with? I mean did you see the "primary key equality" thing? Holy shit. > — [d1l on hackernews](https://news.ycombinator.com/item?id=50318520) > > We now run sustained Jepsen workloads daily alongside our own test suites. Why would anyone believe you when you say this? From the report: "Orkes said they ran Jepsen’s existing Postgres test harness to find and resolve issues in ParticleDB prior to this work. However, that same test harness failed immediately when run against ParticleDB 1.1.4. Orkes also stated they tested ParticleDB with SQLancer, which generates far more complex queries than the ones we tested. It is therefore perplexing that nearly every feature we tested exhibited glaring errors, and that our findings seemed to come as a surprise. Most databases have a test suite which exercises at least basic examples of each feature, and it is customary to run those tests before release, if not continuously. Where were those tests for ParticleDB? How does one add support for NOT NULL constraints without a test which tries to insert at least one NULL value? What development process adds a CHARACTER(10) type without trying to write a string of (e.g.) five characters? Our findings suggest structural deficiencies in the ParticleDB QA process. Perhaps tests were not run prior to release. Perhaps the test suite was run, but failed to exercise basic functionality. Perhaps engineers entrusted Large Language Models with the work of testing." > — [sciurus on hackernews](https://news.ycombinator.com/item?id=50320169) > I'm part of the ParticleDB team. We took these findings seriously and have spent the past few months addressing them and strengthening our testing. We now run sustained Jepsen workloads daily alongside our own test suites. We've also narrowed the supported transaction modes to focus development and testing on core correctness. Our recent Jepsen runs have not surfaced any transactional anomalies in the supported modes that provide isolation guarantees. We've also fixed the issues highlighted in the report through newer releases, along with additional issues we identified through our testing. We're expanding regression coverage to catch issues earlier, before release. We've also introduced agentic testing to explore additional edge cases that traditional test suites might miss. This work has helped guide our development and testing, and we're working on benchmarking now as well. > — [nikez96 on hackernews · 7 comments](https://news.ycombinator.com/item?id=50319275) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50316100) · 148 points · 86 comments - [lobsters](https://lobste.rs/s/drwd4j/jepsen_particledb_1_1_4) · 67 points · 12 comments ## Similar posts on daily.dev - [building sqlite with a small swarm](https://daily.dev/posts/building-sqlite-with-a-small-swarm-pbrqz4xyf) · Hacker News · 1 upvotes · 0 comments --- Tags: [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/jepsen-particledb-1-1-4-duaeyv6xm) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Jepsen: ParticleDB 1.1.4","url":"https://daily.dev/posts/jepsen-particledb-1-1-4-duaeyv6xm","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/jepsen-particledb-1-1-4-duaeyv6xm"},"datePublished":"2026-10-31T18:49:32.435Z","dateModified":"2026-10-31T22:35:45.581Z","description":"Jepsen tested ParticleDB, a Rust database built by Orkes that unifies SQL, key-value, vector search and analytics, and found 96 issues. Most bugs occurred on a...","image":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","thumbnailUrl":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/jepsen-particledb-1-1-4-duaeyv6xm","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"rust","timeRequired":"PT72M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Jepsen: ParticleDB 1.1.4"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/jepsen-particledb-1-1-4-duaeyv6xm#faq","mainEntity":[{"@type":"Question","name":"What consistency model does ParticleDB's occ transaction mode actually provide?","acceptedAnswer":{"@type":"Answer","text":"ParticleDB's occ mode (also called occ-v3, occ-v2, or row-2pl) provides snapshot isolation, not full serializability, according to an unpublished Orkes operator guide. The zero-copy-occ mode also provides snapshot isolation, while serializable-ssi provides serializable and table-2pl (aka serializable) provides strong serializable. Despite this, ParticleDB's marketing described the database as offering 'Full ACID'. Checking what isolation level a database mode truly offers before trusting it in production is easier with sources developers track on daily.dev."}},{"@type":"Question","name":"Is ParticleDB's table-2pl transaction mode usable in production?","acceptedAnswer":{"@type":"Answer","text":"In versions 1.1.4 through 1.1.18.4, table-2pl was essentially unusable because most transactions took 10, 20, or even 30 seconds before failing with errors like 'could not serialize access due to concurrent update'. High latency issues appeared improved by version 1.1.18.6, though deadlocks under table-2pl persisted until 1.1.18.11.rc-7. Evaluating whether a database's strictest isolation mode holds up under load is the kind of due diligence daily.dev readers follow."}},{"@type":"Question","name":"Did Jepsen find violations of snapshot isolation in ParticleDB after most bugs were fixed?","acceptedAnswer":{"@type":"Answer","text":"Yes, between versions 1.1.18.11.rc-1 and 1.1.18.11.rc-22, testers occasionally observed G-single, a phenomenon similar to lost update that violates snapshot isolation, on single nodes with no faults, using the occ-v3 and zero-copy-occ transaction modes. Orkes reported that version 1.1.19-rc.13 no longer exhibited G-single after the collaboration. Tracking which database versions still fail formal consistency checks matters before you commit to one on daily.dev."}}]} ```