See also:

Fuzzer Blind Spots (Meet Jepsen!) – https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-m...

Very impressed with this report. Whenever I read TigerBeetle's claims on reliability and scalability, I'd think "ok, let's wait for the Jepsen report".

This report found a number of issues, which might be a cause for concern. But I think it's a positive because they didn't just fix the issues, they've expanded their internal test suite to catch similar bugs in future. With such an approach to engineering I feel like in 10 years TigerBeetle would have achieved the "just use Postgres" level of default database in its niche of financial applications.

Also great work aphyr! I feel like I learned a lot reading this report.

Really happy to see TigerBeetle live up to its claims as verified by aphyr - because it's good to see that when you take the right approach, you get the right results.

Question about how people end up using TigerBeetle. There's presumably a lot of external systems and other databases around a TigerBeetle install for everything that isn't an Account or Transfer. What's the typical pattern for those less reliable systems to square up to TigerBeetle, especially to recover from consistency issues between the two?

This is a particularly fun Jepsen report after reading their fuzzer blind spots post.

It looks like the segfaults on the JNI side would not have been protected if Rust or some other memory safe language were being used - the lack of memory safety bugs gives some decent proof that TigerBeetle's approach to Zig programming (TigerStyle iirc, lol) does what it sets out to do.

Love the wonderfully detailed report. Getting it tested and signed off by Jepsen is such a huge endorsement for TigerBeetle. It’s not even reached v1.0 and I can’t wait to see it hit new milestone in the future.

Special kudos to the founders who are sharing great insights in this thread.

A small appreciation for the section entitled "Panic! At the Disk 0": <golf clap>

I think it is interesting but obvious in hindsight that it is necessary to have the distributed system under test report the time/order things actually happened to enable accurate validation against an external model of the system instead of using wall-clock time.

The articles link to the paper about "Viewstamped Replication" is unfortunately broken (https://pmg.csail.mit.edu/papers/vr-revisited.pdf connection refused).

I think it should be http://pmg.csail.mit.edu/papers/vr-revisited.pdf (http scheme not https) ?

And now I have some Friday evening reading material.

I have a question that I hope is not misinterpreted, as I'm asking purely out of a desire to learn. I am new to distributed systems and fascinated by deterministic simulation testing.

After reading the Jepsen report on TigerBeetle, the related blog post, and briefly reviewing the Antithesis integration code on GitHub workflow, I'm trying to better understand the testing scope.

My core question is: could these bugs detected by the Jepsen test suite have also been found by the Antithesis integration?

This question comes from a few assumptions I made, which may be incorrect:

- I thought TigerBeetle was already comprehensively tested by its internal test suite and the Antithesis product.

- I had the impression that the Antithesis test suite was more robust than Jepsen's, so I was surprised that Jepsen found an issue that Antithesis apparently did not.

I'm wondering if my understanding is flawed. For instance:

1. Was the Antithesis test suite not fully capable of detecting this specific class of bug?

2. Was this particular part of the system not yet covered by the Antithesis tests?

3. Am I fundamentally comparing apples and oranges, misunderstanding the different strengths and goals of the Jepsen and Antithesis testing suites?

I would greatly appreciate any insights that could help me understand this better. I want to be clear that my goal is to educate myself on these topics, not to make incorrect assumptions or assign responsibility.

Curios if they got any large bank or stock exchange to use TigerBeetle

TigerBeetle is something I’m interested in. I see there is no C or Zig client listed in the clients documentation. Thought these would be the first ones to exist given it is written in Zig. Do they exist or maybe still WIP?

I found the line about Tigerbeetle's model assuming entire disk sector errors but not bit/byte errors rather interesting - as someone who has created error correcting codes, this seems out of line with my understanding. The only situation I can see it works is where the disk or driver encodes and decodes the sectors... and (on any disk/driver I would care to store an important transactional database) would be reporting tonnes of (possibly corrected) faults before Tigerbeetle was even aware.

Or possibly my mental model of how physical disks and the driver stack behave these days is outdated.

If memory serves, TigerBeetle is/was not free for production? I can't find the Pricing page, but I kinda remember reading about it somewhere (or it was implied) a while back.

TigerBeetle is impressive, but it's a single purpose DB. Unless you fit within the account ledger model it's extremely restrictive.