raft VS tigerbeetle

Compare raft vs tigerbeetle and see what are their differences.

raft

Golang implementation of the Raft consensus protocol (by hashicorp)

tigerbeetle

A distributed financial accounting database designed for mission critical safety and performance. [Moved to: https://github.com/tigerbeetledb/tigerbeetle] (by coilhq)
Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
raft tigerbeetle
7 37
7,787 1,012
1.5% -
6.1 9.5
3 days ago over 1 year ago
Go Zig
Mozilla Public License 2.0 Apache License 2.0
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

raft

Posts with mentions or reviews of raft. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-07-07.

tigerbeetle

Posts with mentions or reviews of tigerbeetle. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-08-10.
  • SQLite Helps You Do Acid
    3 projects | news.ycombinator.com | 10 Aug 2022
    Indeed!

    I was so glad to see you cite not only the Rebello paper but also Protocol-Aware Recovery for Consensus-Based Storage. When I read your first comment, I was about to reply to mention PAR, and then saw you had saved me the trouble!

    UW-Madison are truly the vanguard where consensus hits the disk.

    We implemented Protocol-Aware Recovery for TigerBeetle [1], and I did a talk recently at the Recurse Center diving into PAR, talking about the intersection of global consensus protocol and local storage engine. It's called Let's Remix Distributed Database Design! [2] and owes the big ideas to UW-Madison.

    [1] https://github.com/coilhq/tigerbeetle

    [2] https://www.youtube.com/watch?v=rNmZZLant9o

  • 20 years of payment processing problems
    3 projects | news.ycombinator.com | 18 Jul 2022
    > By shifting business logic to stored procedures you avoid this.

    Thanks, we considered stored procedures to bring the number of database queries down from 18 queries per payment to 1 query per payment. However, that would have provided only an order of magnitude improvement, and brought with it complexity of testing, compared to the state machine [1] we have in TigerBeetle.

    At the same time, the biggest performance bottleneck is not only the multiple roundtrips, but the lack of first-class batching in the interface. What we do in TigerBeetle instead, is we send 8192 transfers in a single network request. This brings the network/disk cost equation down from 1 query per payment, to 1/8192 query per payment. It's like group commit, on steroids.

    [1] https://github.com/coilhq/tigerbeetle/blob/main/src/state_ma...

    > That's also why SQLite is very fast, as it runs in your application's memory as a library. But then your data is tied to the same limitations as the machine the application is on.

    We could have made SQLite distributed, but SQLite also does not solve our storage fault model. For example, misdirected reads/writes, lost reads/writes, bitrot in the middle of the committed log. SQLite was also not explicitly designed to be integrated with a global consensus protocol as per ”Protocol-Aware Recovery for Consensus-Based Storage” from UW-Madison. For example, there are optimizations around storage fault tolerance in the commit log that you can do, or around deterministic storage across replicas for faster recovery, that you can't do with SQLite.

    3 projects | news.ycombinator.com | 18 Jul 2022
    I had the experience of being part of a team in 2020 doing performance and safety analysis on Mojaloop [1], the open-source payments switch. The emphasis was mostly to identify performance bottlenecks. For example, graphing waterfalls of database queries, estimating expected vs actual concurrency, digging into latency spikes, timeout interactions, and missed group commit opportunities.

    However, on the safety front, one of the most challenging issues was guaranteeing the rollback of funds in the event of failure, as part of the two-phase commit money transfer protocol, and coordinating this across multiple SQL queries, database transactions, Kafka queues, even multiple code repositories, especially as different systems experience clock drift or as disks or machines fail.

    You want to ensure that the money either moves, or doesn't move, that it doesn't get lost somewhere in between.

    Most payment systems re-implement all this business logic, again and again, so we extracted this from Mojaloop once-and-for-all, to create TigerBeetle [2], an open-source financial accounting database, that provides multi-AZ replication, automated leader election, and two-phase payments out-of-the-box.

    [1] https://mojaloop.io

    [2] https://github.com/coilhq/tigerbeetle (Zig)

    3 projects | news.ycombinator.com | 18 Jul 2022
    > It sounds like payments might be part of the larger concept of declarative programming (DP)

    Yes, exactly! The idea with TigerBeetle's state machine [1] is to expose double-entry accounting as higher level financial primitives, so that developers can think in terms of declaring transfers from one account to another. The business logic behind the scenes is detailed, but the interfaces and data structures are simple.

    [1] https://github.com/coilhq/tigerbeetle/blob/main/src/state_ma...

    > Maybe TigerBeetle could be generalized to support any multi-step distributed process?

    That's part of the plan, that the distributed database framework of TigerBeetle can be used as a ”distributed Iron Man suit” to support any kind of state machine.

  • How Safe Is Zig?
    8 projects | news.ycombinator.com | 23 Jun 2022
    It's a pleasure. Let me know if you have any more questions about TigerBeetle. Our design doc is also here: https://github.com/coilhq/tigerbeetle/blob/main/docs/DESIGN....
  • Distributed Systems Shibboleths
    3 projects | news.ycombinator.com | 2 May 2022
    > Allowing developers to think about a stream of operations that moves the databases from one legal state to another is super powerful.

    It is super powerful. We used this RSM intuition to test TigerBeetle's strict serializability, by verifying state transitions the instant they happen, instead of trying to piece everything together and verify strict serializability after the test run.

    Here it is in 49 lines of code:

    https://github.com/coilhq/tigerbeetle/blob/477d6df366e2c10fa...

    3 projects | news.ycombinator.com | 2 May 2022
    Surprisingly, some of the most powerful distributed systems algorithms or tools are actually deterministic. They're powerful because they can "load the dice" and so make the distributed system more intuitive for humans to reason about, more resilient to real world network faults, and do all this with more performance.

    For example, Barbara Liskov and James Cowling's deterministic view change [1], which isn't plagued by the latency issues of RAFT's randomized dueling leader problem. Viewstamped Replication Revisited's deterministic view change can react to a failed primary much quicker than RAFT (heartbeat timeouts don't require randomized "padding" as they do in RAFT), commence the leader election, and also ensure that the leader election succeeds without a split vote.

    Determinism makes all that possible.

    Deterministic testing [2][3] is also your best friend when it comes to testing distributed systems.

    [1] I did a talk on VSR, including the benefits of the view change — https://www.youtube.com/watch?v=Wii1LX_ltIs

    [2] FoundationDB are pioneers of deterministic testing — https://www.youtube.com/watch?v=OJb8A6h9jQQ

    [3] TigerBeetle's deterministic simulation tests — https://github.com/coilhq/tigerbeetle#simulation-tests

  • Lies we tell ourselves to keep using Golang
    8 projects | /r/fasterthanlime | 29 Apr 2022
    This is the chasm problem, where people don't use a technology because people aren't using that technology, thus the technology has difficulty gaining adoption. I did see that Zig does have it's own killer app and startup that's using Zig: TigerBeattle.
  • Ask HN: Codebases with great, easy to read code?
    35 projects | news.ycombinator.com | 21 Mar 2022
    Are we allowed to share repos that we've written? :)

    If so, then here's distributed consensus written in Zig:

    https://github.com/coilhq/tigerbeetle/blob/main/src/vsr/repl...

    Something that differentiates this from many other consensus implementations is that there's no networking/multithreading code leaking through, it's all message passing, so that it can be deterministically fuzz tested.

    I learned so much, and had so much fun writing this, that I hope it's an enjoyable read—or please let me know what can be improved!

    35 projects | news.ycombinator.com | 21 Mar 2022
    Control flow statements should always be on their own lines, then it's easy to find all of them by visually scanning top-down, without needing to look all the way down each line.

    [1]: https://github.com/coilhq/tigerbeetle/blob/main/src/vsr/repl...

What are some alternatives?

When comparing raft and tigerbeetle you can also consider the following projects:

serf - Service orchestration and management tool.

tendermint - ⟁ Tendermint Core (BFT Consensus) in Go

torrent - Full-featured BitTorrent client package and utilities

etcd - Distributed reliable key-value store for the most critical data of a distributed system [Moved to: https://github.com/etcd-io/etcd]

dragonboat - A feature complete and high performance multi-group Raft library in Go.

DHT - BitTorrent DHT Protocol && DHT Spider.

ringpop-go - Scalable, fault-tolerant application-layer sharding for Go applications

grpc-go - The Go language implementation of gRPC. HTTP/2 based RPC

raft-grpc-example - Example code for how to get hashicorp/raft running with gRPC

Olric - Distributed in-memory object store. It can be used as an embedded Go library and a language-independent service.

go-health - Library for enabling asynchronous health checks in your service

redis-lock - Simplified distributed locking implementation using Redis