Jepsen found 96 issues in ParticleDB. HN argued about vibe coding; the lesson is a test you have seen fail

Kyle Kingsbury's Jepsen report on ParticleDB landed on 31 October: "We present 96 issues in ParticleDB", and "Most issues required just a single server, single client, and no faults." The Hacker News thread ran to 142 comments from 89 people, and most of the heat went to one question: was it vibe coded? Our read: that is the least useful question in the thread. The report's own answer is about process. The vendor said it had run Jepsen's Postgres harness and SQLancer, and the harness "failed immediately" against the release Jepsen tested. Having tests was never the problem. Nobody was treating a failing test as a stop sign.

What the thread talked about

We counted keywords across the 142 comments. 39 mention LLMs, AI, agents or vibe coding. 36 mention tests or testing. 19 compare ParticleDB with Postgres, MySQL or MongoDB history. 13 mention TLA+, formal methods or proof. 9 quote WHERE 4 = 5, the query that returned a row.

Camp 1: "formally proven" was never the safety net

The report notes that ParticleDB's home page advertised it as "formally proven" with a TLA+ proof, but "during our collaboration no TLA+ specification was available." lumost put the general point bluntly: "TLA+ doesnt prove the code" (lumost). hibikir added a war story: "I had to fix a proven correct distributed algorithm that just happened to believe updates were done atomically and with no latency" (hibikir).

jen20 kept Jepsen in its lane too: "it proves the presence of bugs, not the absence of them. It is not formal verification, just a more rigorous form of existential testing" (jen20). Both kinds of evidence are worth having. Neither covers code that nobody pointed it at.

Camp 2: the vendor says it is fixed

A commenter from the ParticleDB team replied: "We now run sustained Jepsen workloads daily alongside our own test suites." They added: "We've also narrowed the supported transaction modes to focus development and testing on core correctness" (nikez96). The report itself records that Orkes "claim that it resolves all remaining issues" in version 1.1.19-rc.13, and that the research was funded by Orkes.

The skeptics' reply was about evidence, not intent. fabian2k: "It might have fewer issues, it likely will have different issues as well though" (fabian2k). That is fair to both sides. Another Jepsen run would settle it. A comment cannot.

Camp 3: the tests existed and did not stop anything

This is the part worth keeping. Section 4.3 of 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."

stevenburg named the missed signal: "If the existing harness breaks right away, that's the signal to stop and fix things, not to book an outside audit" (stevenburg). shoo wrote the most practical comment in the thread, a list of what running the suite in CI quietly assumes. It includes "test cases are implemented correctly - i.e. they actually fail if the implementation is defective" and "failing tests block changes from being merged" (shoo).

The report says the same thing in one sentence: "Observing these failures is an important part of the development process: it validates that the test measures something."

Camp 4: what LLMs changed, and what they did not

aphyr confirmed that "Orkes did, in fact, ask AI agents to test ParticleDB in-house prior to our collaboration" (aphyr). danpalmer described the failure mode: "The human's goal is to produce a working database engine, the LLM's goal is to pass the test suite or implement the spec it has been given" (danpalmer). The report's version is sharper: "LLM tooling repeatedly claimed that bugs had been fixed when, in fact, they had not."

TexanFeller asked the question the thread skipped: "Is there any concrete evidence they vibe coded it?" (TexanFeller). The useful contrast came from someone who had been through a Jepsen engagement: "We took things seriously and wrote a significant amount of testing ourselves, and by the time our engagement began, we were pretty confident" (xyzzy_plugh).

The release gate, as the thread and the report describe it

The takeaway

None of these rows needs Jepsen, TLA+ or a model. They are the cheap gates, and they apply whether an engineer or an agent wrote the code. The report's own advice is to write the test first, watch it fail on the unimplemented feature, and only then believe it when it passes. Agents make that matter more, because "fixed" is now a claim made at machine speed.

Caveats. One report and one thread, sorted by us. The keyword counts are regex matches, so a comment can count in several rows. The vendor states that later releases resolve the reported issues; we have not tested them.