Top
Best
New

Posted by aphyr 11 hours ago

Jepsen: ParticleDB 1.1.4(jepsen.io)
https://github.com/jepsen-io/particledb
186 points | 97 commentspage 3
Thaxll 8 hours ago|
Slop DB written in Rust. They probably changed the landing page after the bad results, you can still see the old one: https://web.archive.org/web/20260518203012/https://particled...

"Written in Rust · Formally Verified · PostgreSQL Compatible"

_bohm 7 hours ago||
Is/was ParticleDB open source? There is a Github link on their website, however the only public repo in their org seems to be the Golang client library.
d5wiz 7 hours ago|
https://github.com/orgs/particledb-ai/repositories

SDKs are MIT license CLI tools and Studio will be also be MIT License

Server is not open source for now but free for developers

foltik 6 hours ago|||
“No.”

Afraid to show the slop?

semiquaver 5 hours ago||
No, they’re aware they don’t possess copyright on the source code because it has not one scintilla of human effort, so keeping it secret is the only legal way to protect it! :)
stacktraceyo 7 hours ago||
Fatality
cyberpunk 4 hours ago||
It’s really great to see more of these @Aphyr, I really enjoy them and learn something from each. Thank you!
NoDodgeQuestion 4 hours ago||
tigerbeetle much different result

https://jepsen.io/analyses/tigerbeetle-0.16.11

https://news.ycombinator.com/item?id=44199592

jwr 5 hours ago||
Every database vendor should pay to get their software Jepsen-tested.
jsyang00 4 hours ago|
I am not sure I would want my database tested by a vendor who feels it their duty to provide color commentary on my software development methodology in a public report, no matter how rigorous their evaluation.
zbentley 3 hours ago|||
The principal values of things like the Jepsen reports is to the community of potential users/purchasers.

I agree with GP, that vendors should be somehow required or very strongly encouraged to participate in such audits. Not because they want to (as you say, most wouldn't like their dirty laundry aired thus), but because consumers deserve to know. U.S. government software groups don't like FISMA/RMF audits either, but they have to do them anyway.

eqvinox 2 hours ago||||
> vendor who feels it their duty to provide color commentary

Honestly? At some point there's a fiduciary-like obligation for it. What ParticleDB delivered is so far past good or bad, it's just straight ugly and then some. It's so poor that, if Jepsen couched it in any way, they'd be implicitly misleading their readers.

phoe-krk 4 hours ago|||
I am of a contrary opinion. At some level of developer insolence, such commentary is valuable - especially if it needs to mention the core basics and foundations that keep the software world running, such as running existing Postgres test suites for a supposedly Postgres-compatible database. In the increasingly sloppified world, even such basics are being eroded - this being a proof.

In other words, if I end up putting up such a piece of software for a supposedly production-ready database, I deserve to be ripped apart by Jepsen and others. Somebody has to assert software quality; if it's not asserted internally, it must be asserted externally.

In yet another words, software development is a trust-based business. If you break it, such as by outright lying to people, then you deal with the consequences.

skinfaxi 3 hours ago||
Dude please set up an RSS feed I've been reading your jepsen posts since like 2014 and haven't realized how much i missed.
aphyr 1 hour ago|
You're in luck! https://jepsen.io/blog has Atom and RSS feeds. :-)
quietbarn 6 hours ago||
I wonder what the internal testing pipeline looked like before this. A codebase with that many fundamental issues suggests either no integration tests were written or they were all mocked out to pass green. It seems strange that a team would market a system as formally proven without actually running the workload through even basic consistency checks themselves first.
Powdering7082 9 hours ago||
-https://github.com/jepsen-io/particledb is currently 404 (probably still private?)-

EDIT: It's up now

aphyr 9 hours ago||
Sorry about that--yes, it's still private. Hoping to have that resolved shortly.
dang 8 hours ago||
Looks like it's up now. I'll put that link in the toptext as well. Thanks!
stevenburg 6 hours ago|
That part is the weird bit to me. If the existing harness breaks right away, that's the signal to stop and fix things, not to book an outside audit. Running the suite in CI on every build would have caught a lot of this.
shoo 4 hours ago|
> Running the suite in CI on every build would have caught a lot of this

yeah, provided:

  1. test cases are being designed to cover functionality
  2. test cases are implemented correctly - i.e. they actually fail if the implementation is defective
  3. the tests aren't all commented out
  4. the test suite fails if a test fails
  5. CI actually detects test suite failure
  6. failing tests block changes from being merged (apart from initial triage to stabilise the suite)

Presumably a few of these things weren't being done -- I'd bet 1 & 2 were skipped or implemented so poorly that they were worse than having no tests at all -- checking nothing but giving a false illusion that some kind of testing had happened.

Five years ago, outsourcing your software development (including QA) to the lowest bidder might have gotten you results like this -- if you didn't explicitly require automated tests as a deliverable, you wouldn't get any, or if you got some they'd be vacuous and not test anything.

jeremyjh 2 hours ago||
They forgot the “don’t make any mistakes” part of the prompt.