Jepsen: ParticleDB 1.1.4
A new Jepsen analysis of ParticleDB, a Postgres-compatible database marketed as “formally proven” and AI-focused, reports an unusually large number of severe correctness bugs, from lost writes to nonsensical query results like `WHERE 4 = 5` returning rows. Commenters argue that the extent and nature of the flaws point to fundamental design and QA failures, likely exacerbated by heavy reliance on large language models, and see the episode as a cautionary tale about hype-driven database projects. Many conclude that such a system is unsafe for production use and that Jepsen-style testing should be a baseline for any serious data store.
Scope and Severity of Issues
- Commenters describe the Jepsen report as unusually damning compared to typical database analyses.
- ParticleDB is said to exhibit numerous severe bugs: crashes, deadlocks, data loss, bizarre SQL behavior (e.g., impossible predicates returning rows, predicates on nonexistent columns), and pervasive transactional anomalies even on a single node without faults.
- Several participants argue this suggests a fundamentally flawed design (“incorrect by construction”), not just localized bugs.
Marketing Claims vs. Reality
- Strong criticism of marketing: claims of being “formally proven” with TLA+, “PostgreSQL compatible,” production-ready builds, and extreme performance claims (e.g., faster than Redis, orders of magnitude faster than Postgres).
- The Jepsen report notes no TLA+ spec was available, and that basic Postgres compatibility clearly failed.
- Some point out that the website and wording appear to have been quietly revised after the test results.
Testing and QA Process
- Many are baffled that such basic bugs shipped: they infer either missing tests, ineffective tests, or tests not being run.
- Jepsen notes that the existing Postgres Jepsen harness supposedly had been run earlier, yet it fails immediately on the tested version.
- Commenters see this as evidence of deep structural QA problems, possibly including over-reliance on automated agents.
Role of AI / “Vibecoding”
- Repeated speculation that large language models were heavily used to write both the database and its tests, with humans not fully understanding the system.
- “Vibecoded database” becomes a shorthand for AI-generated, poorly validated code and documentation.
- Some note that AI can be powerful in capable hands, but here it appears to have amplified inexperience and poor judgment.
Vendor Response and Future Trust
- A team member states that the issues have since been addressed, the engine redesigned, daily Jepsen workloads are now run, and testing has been strengthened.
- Most replies are highly skeptical: fixing listed bugs is called “table stakes,” and people question why a system this immature was marketed as production-ready and formally verified.
- Several say they would never deploy the product; some suggest starting over or leaving the space entirely, citing reputational damage.
- A minority emphasizes that Jepsen’s purpose is to find bugs so they can be fixed and that surviving future Jepsen runs could restore some trust.
Broader Takeaways
- Many argue every database vendor should undergo Jepsen-style testing, and that candid, even harsh reports are necessary to protect users.
- The thread highlights a contrast between rigorous, test-driven database engineering and hype-driven, AI-accelerated development that neglects correctness.